Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm considering running a project using the Agile methodology but the project is roughly 9 months work for 6 developers. Is this project too big to run under as Agile?
Obviously ignoring the risks associated with running the first Agile project on this size.
Thanks,
Mike
Edit
Thanks for all the answers. I have no experience of Agile neither do I have a Scrum Master or anyone with much xp. My original thoughts were how to run an agile project as I haven't architected the system yet. So how do I run a team on a project which doesn't have architecture when the project will last 9-12 months.
Clearly I need to dedicate more time to understanding the principles before I dive in.
No, it's not too big at all. However, your question to me seems to imply a kind of casual approach to methodology choice and perhaps an unfamilarity with Agile generally, or you wouldn't ask it - which Agile methodology were you intending to use? Have you experience in that or in other Agile development approaches? How are you proposing to train peoole in what to do?
You have a typical setup here. 6 devs, room for several iterations.
If you had more developers, I would have recommended you to split them into smaller teams.
Project duration is less important since the approach is iterative and let you develop tbe most useful features first.
The project isn't too big to run as an Agile project.
However, you haven't mentioned any other team members.
Do you have testers and either business users or a BA who can act as a proxy, sat with your developers?
Do you have stakeholders who are prepared to engage and give you regular feedback?
Are your infrastructure team ready to provide you with the environments you'll need for more frequent testing, continuous integration, etc?
Are your architects happy to work in an incremental, evolutionary way?
Do you have a facilitator or coach who can make a safe environment to run retrospectives in?
Are the project board prepared to receive different kinds of reports and metrics?
Are you in a good place to learn and will the people around you make it safe for you to do so?
On an Agile project, the word "team" can be misleading, and the impact of the first Agile project is usually a lot bigger than anyone thinks it will be. Still not too big, though - good luck with it!
The Scrum Guide states:
The optimal size for a Team is seven people, plus or minus two. When
there are fewer than five Team members, there is less interaction and
as a result less productivity gain. What’s more, the Team may
encounter skill constraints during parts of the Sprint and be unable to
deliver a releasable piece of the product. If there are more than nine
members, there is simply too much coordination required.
Keep in mind "Team" in this context is part of the Scrum Team which also includes the Scrum Master and the Product owner, who are just as key. Do you have a person for each of those roles?
Granted, the Scrum Guide may not be a bible, but it's a good starting reference, especially for someone new to Scrum. But I'd say 6 is a good size for your team.
Are you working with a coach or someone on the Scrum Team who is experienced in Scrum? If not, there's a fair chance that you won't understand a number of key concepts. Said a different way, it's difficult to learn scrum from reading about it and trying it. Often teams that take that approach run into barriers, abandon Scrum, then tell people that "Agile doesn't work" because their project failed.
Is this project too big to run under as Agile?
No. Since you seem to be in the Agile and Estimation and Planning phase it, watch this video.
http://www.youtube.com/watch?v=FkWglejhJZM
Mike Cohn (author of Agile Estimation and Planning) talks about a 700 people Scrum Project, divided into roughly 100 Teams, which clearly is a several month project.
Now would you think of your project being big? :)
I would call your project and team as relatively small. Agile methodologies are better for small teams, but the project size doesn't really matter.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
After working Scrum(ish) in a previous workplace, I am trying to implement it in my new place of work for a brand new project (I am no scrum expert). We have some pre-requisites to code before we can begin working on the stories (which are being groomed in the mean time). Things like database design, api design, etc. We plan to use two week iterations and it's just not clear to me how the first one (or two) can provide something useful to the customer and "potentially shippable" if we first have to "lay down some groundwork" ? Any ideas on how to treat this?
What you are experiencing is very typical of new teams wanting to move to Scrum where they are coming from more of a traditional process. Adapting to Scrum is very, very hard and we always say this, and the reason for this is there needs to be many mindset changes.
The first change the team should understand is that when bringing a PBI (requirement) into a Sprint, it only a well defined requirement with nothing else. This means there is no designs, database schemas or API's for the requirement. The team has to do all of this in the sprint, plus build and test the requirement.
If you are new to Scrum, you most probably are squirming in your seat thinking it cannot be done. You are likely right for now, but this is where the hard work comes in ... changing the way teams work. This is hard.
Some pointers :-
Small Requirements - Most teams suffer from poor, ambiguous requirements which previously took days to design, build and test. The art is to learn to break these EPIC requirements down into smaller incremental requirements where each one builds upon the previous, but explicitly adds business value. Now, I am going to be blunt here ... this is the biggest challenge for most teams. Personally, I have been training/coaching Scrum for a number of years now have not found any feature that cannot be broken down into small requirements with an average estimate of 2-3 days to fully complete.
Team composition - The team needs people in it with all the skills necessary to design, build and test the PBI. They should not have dependencies on other people outside of the team. Having dependencies, cripples teams but it highlights to management there are not enough people with the specialised skills.
Sprint Planning - Sprint planning should be used to do high level designs and discuss how the team is going to tackle delivering each requirement. Many teams waste their sprint planning by clarifying weak requirements and debating the requirement. This is a sign of weak requirements and it should be addressed. Sprint planning is about discussing How to build/test a PBI and not What.
Coach - I would really recommend you hire an experienced contract coach/consultant to get you going and do things right. Trying to do this by yourself, just leads to a world of unnecessary pain.
Architecture - At the inception of the project, there is nothing wrong for the team and architects to spend a day or two brainstorming the macro architecture of the product and discussing the technologies to be used. However, when it comes to new requirements they are designed and adjusted into the product. This sounds hard, but with the correct software engineering patterns using SOLID principles, well defined patterns as well as strong Continuous Integration and Unit Testing. The risks of a bad architecture are eliminated. There is not question that the team should have a member in it that has the skills to design an architect the new requirements. [There is lots of evidence on the web that an evolving architecture with re-factoring results in a better application than a big upfront architecture - but that another debate]
Application Lifecycle Management - Invest in strong ALM tooling with CI, unit testing, test lab, continuous deployment. Having the right tools for the team allows you to deliver quickly, and a lack of these totally cripples you. CI with automated testing is essential for an incremental product as there is fast and constant change and you want to protect that a change does not break a previous requirement.
ScrumBut - Ken and Jeff no longer support the use of the term ScrumBut as it is perceived as elitism and often comes across as belittling. Instead it is preferred that teams are on the journey to implementing Scrum and helping them through coaching.
Welcome to your journey into Scrum, hang in there as it is very hard initially. Once you fully "get it", then you and your company will be really happy that you did.
In an ideal world, Technical pre-requisites should be factored into the estimate of each story and you should only implement "just enough" to complete the story. See "Do The Simplest Thing That Could Possibly Work"
Why do you need to design the API or the Database? Try to avoid Big Up front design. Avoid building Frameworks up front, apply YAGNI
It's hard for you to understand how you could ship something in two weeks because you have the cart before the horse; that is, your priorities are wrong. The important thing is delivering customer software - not building databases or API designs.
This is a trade of against long term productivity and you should avoid accruing too much technical debt. Many Agile methodologies would argue that up-front work like this will be wrong and therefore should be avoided to minimise waste. Lean software recommends defering decisions to the Last Responsible Moment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
While studying a software methodologies, I often see disclaimers along the lines of "This methodology requires a mature development team."
Which development methodologies are specifically geared towards immature development teams? I'd assume this is where most teams should start.
Let's define an immature team as a team whose members haven't worked together before, are working in an unknown environment (i.e. new company), and who haven't defined their processes and controls yet.
My $0.02
It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off".
(Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like #BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, #Bill's and #Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
When I installed MS-TFS 2008, I started to get myself prepared to use the Agile Process Guidance template, that was shipped with the TFS server. With a little googling, I went through Mike Cohn materials:
I watched his conference in youtube "sponsored by google":
http://www.youtube.com/watch?v=fb9Rzyi8b90
http://www.youtube.com/watch?v=jeT0pOVg0EI
Read his book "Agile Estimating and Planning"
Watched the video series in his website: http://www.mountaingoatsoftware.com/presentations-tag/video-recorded
I was very happy while absorbing and eating the techniques he uses with the teams and how agile and Scrum are both such a great software process/methodology, until I saw Mike answer a question regarding the architect role and talking about the requirements document... at that point everything start falling apart, due to the following:
Last year I had been assigned to make full analysis "including requirements gathering" for big project, "very high priority project".
Within 2 months of hard work, dedication and commitment I delivered the whole analysis with full satisfaction of the customer and my BOSS and ZERO amendments.
Later on, the project entered the architecture, development ... phases.
Due to the fact that the system included many competitive and exciting features, I requested patenting it and its going in the process...
So imagine you are the kind of person who used to love facing all kinds of challenges and returning with excellent experience and results for the stakeholders and yourself, How fairly agile and scrum processes will credit and admit your talent and passion while the scrum master/coach treat the team as one unit that accomplish user stories and converge through trial and error approach??!!!!
With those dark thoughts about agile and Scrum I found many people "anti agile" and on top of them is "Crispin Rogers Johnson":
http://agile-crispin.blogspot.com/
That guy made an anti-statement for everything Mike Cohn used to talk about.
I really don't know what to do next! So any guidance will be appreciated.
Thanks,
For every project there is a correct development strategy. If NASA used agile or scrum they would not have the 1 in 100,000 lines of code defect rates that satelite system requires. You can't release and iterate away the bugs. If you do you wind up watching your system crash into Mars.
That said, you shouldn't have to spec out in excruciating detail every nuance of a website which is related to some Hollywood mogul's dog or fansite. That's something you'd iterate and fix while the customer gave you feedback.
There is a balance to everything and every a balance. Perhaps you should read a book like, Rapid Development. While it's slightly dated so is the mythical man month but both have lasting values. What these should teach is that there is no one way to do things but many. The project should dictate your approach not some evangelical software guru.
Disclaimer: This is in no way meant to imply that non-Agile are for "real" uses while Agile should be relegated to Scruffy McPointless projects.
As Wheaties mentioned, one strategy does not fit all situations. Agile approaches are usually well suited for products where either requirements are not known very well at the start and/or will be changing. The product is refined as the system is build iteratively and brought in-line with the customer's vision through collaboration with the customer. Now at the same time, from what I have seen, safety or something really expensive and unrecoverable e.g., a satellite, is usually not among the list of concerns for these projects.
Scrum and XP provide best practices for dealing with the management and engineering effort of being Agile respectively. You should freely adopt/modify these best practices for your circumstances but at the same time keep checking your implimentation against the spirit of Agile Manifesto.
Lastly, this interview with Linda Rising on InfoQ looks into if Agile is scientifically proven. Basically, are people in the Agile community giving themselves a "Sugar Pill"?
Interview Excerpt
Science is about experiments, about holding an idea for a short period of time and testing it and then examining the results of that test to find out whether or not the hypothesis holds up. That's really what Agile is about. Agile is about small experiments. I now believe that everything we do, not just software development, but our lives should be a series of small experiments.
We bring in every possible stakeholder, we bring in customers, we bring in users, testers work with developers. We are always examining carefully those sugar pills. Does it really work? What do you think? Are you happy with the results? That's the only thing that saves us - Agile itself. This series of small experiments.
How fairly agile and scrum processes will credit and admit your talent and passion while the scrum master/coach treat the team as one unit that accomplish user stories and converge through trial and error approach??!!!
If your PO is happy, the customers are happy, your BOSS is happy and your product is successful; then you should expect to see yourself and the team justly rewarded through increased pay and or other incentives (like vacation, stock, free lunch).
If you are looking to have Sunshine blown up you ass every day because of your "heroic" efforts that saved the day again then scrum will greatly disappoint you since agile processes by nature look to eliminate the hero position.
By the way you described your successful "2 month analysis" I would guess that your project was so well defined and or your niche so slow that you would have been successful no matter what process you used. Scrum shows its true advantage when you can't spend 2 months and come up with all the requirements and design.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We have proposed to use Scrum in our IT Project and our Adviser asks us if it is appropriate to us because we are still amateurs.
Is it appropriate to us Scrum even if we are amateurs?
The discussion is usually agile vs. waterfall, right? I am linking an article, but it is in Portuguese, so I'll try to transmit some of its ideas:
Waterfall is like chess. You think and plan a lot, try to foresee every possible issue as soon as possible. There's a lot of planning, but makes sense only on stable and well-known domains, where change isn't much expected.
Agile is like soccer (or many collective sports): decisions are made in-game and should be done fast. There's no much time to analyze every consequence. It is "ideal" for dynamic and unstable domains, where change is always expected (web applications, for instance, tend to fall in this category). Another point to note is: even if you have the best players, if they don't do well as a team, you won't be the winner.
IMHO, Scrum would be useful, because:
Once every two weeks (or every month, depending on iteration time) you'll be able to see what's working or not. And this is very valuable, specially as an "amateur" team, which is expected to be learning and finding things out much more constantly.
As amateurs, you probably won't be able to foresee everything (and that's something agile embraces)
There's more space for sharing experience (stand-up meeting, retrospective, and even planning meeting). And you share REAL experience (you must write code every week rather than just plan)
Here's the rub. I think Scrum is going to be tricky not because your team is a bunch of amateur developers but because your team is a bunch of Scrum amateurs. If you have an experienced Scrum Master, your team may reap the benefits of Scrum. Without a point person with Scrum experience, however, there's going to be overhead in learning as you go and more than likely you will get off the Scrum path quickly. At best, you will exercise a modified-Scrum approach (which isn't necessarily a bad thing.) I don't mean to sound negative or doubt your team's ability to practice Scrum, it's just best to have someone with prior Scrum experience before your team dives in. Best of luck.
Scrum, along with other agile methodologies, is not appropriate for a team that consists of students or otherwise inexperienced people.
Wikipedia has a good section on the suitability of agile software development. Barry Bohem and Richard Turner, leading software engineers, wrote a book that includes factors that can help determine if a plan-driven or agile methodology is better on a given project. One of the cases where plan-driven methodologies stands out is with junior developers, which includes students and amateurs.
Now, this doesn't mean that you need to use only a plan-driven approach. I personally think that the most important thing you can do is to find a process that works for your team. You can probably incorporate agile approaches - test driven development, continuous integration, pair programming - into a plan-driven environment that visits each lifecycle stage once.
I disagree. Scrum is better in a situation where
you can depend on the "players"; and,
the requirements might very well be changing underneath you.
A college type project generally has pretty good requirements AND the potential of flaky team members.
Further, you have to think about the purpose of even doing the project in that setting. The students need to think, plan, and discuss how things are going to work before they start diving in. Finally, scrum works best in a close knit, fast paced environment with constant communication. Which is unlikely to happen on a school assignment.
Scrum encourages a "let's just start" programming attitude which, again, is fine when you have experienced professionals working on it that through experience know the pitfalls to avoid up front.
No one says you have to fully implement SCRUM.
I can say from personal experience that SCRUM is great for 'amateurs' :) . At my 4th semester, we had to make a project in the scope of 4 months. Our group of 4 managed "semi-SCRUM" like this:
Sprints were of 2 weeks
No daily stand-up meetings (We were physically close, so we took everything on the fly)
All sprints had a headline from the start of the project. These were our milestones.
We had 2 weeks of buffer time, since we expected to delay :)
SCRUM itself is rather complex, but the ideas of sprints, part-deleverances, leadership and the likes are great. It doesn't really take more than a day for everyone to understand these concepts. For us, SCRUM made sure we had a top-notch project ready by the deadline, with tons of feedback during the development. Top grade too :)
There will always be some team dynamics to get worked out for how things like the daily stand-ups, storyboard and other Agile practices mature in a group. The big question to my mind is whether or not you have enough time to reap some of the benefits that comes after a few sprints and some rhythms have formed within a group. I would suggest at some point calling in someone more experienced with Scrum to give feedback about how to improve what you have as part of the methodology is to grow and evolve over time, IMO.
So, it is fine for you to use Scrum and see how it goes. After all, everyone has to get started somewhere and various modifications on the methodology are common to my mind. There is something to be said for how you'll walk the walk which may be easier or harder than you imagine. Good luck and I do realize this is echoing a lot of Ben's excellent answer.
I think your main problem is going to be in the estimation and tracking to the planned sprint duration. In the past, I’ve found that when resources are not intimately familiar with the coding environment they’ll be working in (this can happen with professionals adopting a new technology), it’s very easy for sprints to go off the rails. Task breakout estimation becomes guesswork and consequently it becomes very difficult to run sprints to plan.
Having said that, there are elements of Scrum which would be very useful in this environment; daily standup meetings and iterative releases are the ones that come immediately to mind. Personally, I don’t subscribe to the “do all of Scrum or you’re not doing Scrum” mantra. Be pragmatic in your approach and pick elements of the methodology which will work for you. Make sure you incorporate the continuous improvement component of doing sprint retrospectives so you can proceed with the assumption of refining and enhancing and you’ll be heading in the right direction.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So I find myself working for a few weeks in a small team of four, including me. Quite a change from my last job at a 300+ developer shop where I'd been part of the adoption of an agile methodology.
I've been sneakily introducing useful tools like a continuous integration server and am surreptitiously starting test-driven development.
What other agile project management and development practices are appropriate for the smaller shop?
Well, to me, your actual configuration is much more appropriated for Agile than a 300+ developer shop (not really sure how Agile was implemented there, I'd love to hear more about that as scaling to that size requires a very high level of maturity on Agile IMO).
So, my answer would actually be: starting with 4 people, all values and practices are appropriate and valuable. Actually, what Agile methodology did you adopt previously? What practices did you implement? What makes you think they wouldn't be appropriate?
PS: If I may, try to see beyond engineering practices, Agile is not (just) about that (this is especially true for Scrum). Practices such as Test Driven Development, Continuous Integration, etc are nice but they are just a mean, not an end. They won't suffice for a successful Agile implementation. Agile is a business oriented organizational pattern. In other words, technical stuff is not really the best starting point when implementing Scrum, you should start with organizational things.
IMHO all of the development practices are appropriate. In fact, for a long time an agile team was expected to be a small teams (5-9 people). There is an artile of infoq about it.
Also, because you have a small team both communication and collaboration will become easier, so the practices would work even better.
Focus on introducing practices that add the most value to the team.
As the team is small impact of the change will be highly visible, if you work with the team and show improvements then you can go back and add another one - again the one that add the most value to the team.
One of the most important thing is that the projects are approached with an agile mindset, adding tools & techniques in the context of long projects that can't adapt to change & are not highly tuned with the customer won't have the ultimate result that you should be aiming for.
Communal code-review whether or not everyone is on the same site
I think you may want to flip the question around; what agile methods would not be suitable because you are a small team. I am no expert in agile practices, but I can't really think of any that would not be appropriate because of your team size.