As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm with a pretty small startup and we started using a form of a Scrum/Agile development cycle.
In many ways I enjoy Scrum. We have relatively short sprints (2 weeks) and I like the Burn Down Chart to track the team's progress. I also like the Feature Board so I always know what I should be doing next. It feels good taking down a feature's card from the board, completing it and then putting it in the burn down pile.
However, we are now entering in our 18th Sprint release cycle and I'm starting to feel a little burnt out. It isn't that I don't like job or my co-workers, it is just that these sprints are... well, sprints. From start to finish I literally feel like I'm racing against the clock to maintain our development velocity. When we are done with the sprint we spend one day planning the next sprint's feature set and estimates and then off we go again.
For people who work in a mature Agile/Scrum development process, is this normal? Or are we missing something? Is there normally time in a Scrum enviornment that is unassigned/untracked to get done some minor things and to clear your head?
This is relatively normal and can sometimes be a complaint of our team members if projects continue for a long period of time.
The key to what we're talking about here is sustainable pace. If you and your team are able to sustain your pace over the long term, that's excellent -- you've achieve the hyperproductivity that all Scrum teams are striving for.
Alternatively, if you're finding that you overestimate how much work you can actually get done in a day, then you may need to reevaluate that during your retrospective. The amount of productive time in a day that a team chooses to recognize when doing their capacity planning for a sprint is referred to as a focus factor.
Henrik Kniberg has this to say:
The “default” focus factor I use for
new teams is usually 70%, since that
is where most of our other teams have
ended up over time.
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf
However, what it sounds like you're talking about is simply the nonstop momentum of sprint after sprint, not necessarily your productivity in a day. Here's some suggestions of things we have tried to deal with that:
End the sprint on a Friday morning. Have your sprint review and retrospective in the morning and let the team work on something else the rest of the day to clear their heads. Pick up with Sprint planning on Monday.
We introduced the notion of "lab days". These are entire days that the team is taken away from the project and they spend the day working on improving their own technical skills through research with each other and collaboration on specific technical topics. Most of the time they have absolutely nothing to do with the specific project and allow team members to think about lighter topics.
From Wikipedia on burnout: "burnout is largely an organizational issue caused by long hours, little down time, and continual peer, customer, and superior surveillance"
They might as well have an icon image of Scrum next to the definition of burnout.
If you think you can send someone onto something else for a brief diversion to fix burnout, you obviously haven't thought it through. Ever go on a vacation after being burned out and go back to work thinking, Wow! Now I'm refreshed and ready for another 6 months of this torture until I finally get a break again. Nope, what happens is you realize, Wow! My job sucks. Now I can really see how my stupid manager's micro-managing, development process is just another way of getting more out of me for less and life's too short for this... I should find something else to do or change jobs to something less stressful.
IMHO, short 2 weeks Scrum should be prohibited except in small doses, not more than 4-8 in a row. Use it as a tool for exceptional or critical things, not continually. Use common sense.
You’re getting worn out after 36 weeks of hard work; that’s not Scrum, that’s human nature! Scrum is not there to make you work harder, it’s there to help you work more consistently and with greater predictability. I often see people confusing the symptoms of normal project management with what they perceive are symptoms of agile methodologies (i.e. “the customer keeps changing requirements – it must be Scrum’s fault!”). It’s an important distinction though because without identifying the cause you can’t treat the symptoms. Personally I’d be looking at ways to reduce burnout such as stress management techniques. There’s heaps of info out there on how to succeed in a stressful environment.
The team that I am currently working on solves this problem really nicely. After three sprints we have a week in which each developer may work on what he wants. Those side projects should be linked to business value, but there is no pressure to get it done. It is a measure to allow us developers to explore new technologies, but it also provides us with a week of more relaxed, fun work.
This for sure helps me to not get burned out.
No matter what development process you're using, if the team is getting burned out something is wrong. It may be as simple as people not taking the vacation time they need, or it could be in the details of how you handle your scrums. Teams are effective over the long-term because everyone gets the rest they need along the way.
A Sprint is not a 100 yard dash; it is one (random) mile in a marathon, i.e. a pace that you can sustain indefinitely.
Is your Team conducting retrospectives at the end of each Sprint? This is the Team's opportunity to "inspect and adapt" their process? As a ScrumMaster, I regularly ask the Team to rate how the Team as an entity 'feels', and if they're having fun. We explore why or why not, and experiment with adjustments and alternatives.
In my experience, Team members enjoy (up to a limit) the 'pressure' that the Sprint timebox constrains. The key is to approach, but not exceed, that zone. As needed, calibrating that zone is a prime checkpoint in a retrospective.
As for "... time in a Scrum environment that is unassigned/untracked to get done some minor things and to clear your head", keeping the Team commitment at x% of the available capacity (points, preferably, but hours can be used if needed; in either case I've found something in the range of 60-70% seems the norm) is key to sustainability inside of a Sprint, and an occasional 'free code day' works well for outside Sprints.
One solution is to reduce the number of hours in the day spent on the sprint.
I know some people whose workdays consisted of a mere two and a half hour of sprint, with the remainder of the day focused on a variety of other activities: support, relieving technical debt, research, etc.. Their development velocity was set accordingly.
That may seem a bit extreme, but if I'm not mistaken it was a profitable company until the recent widespread economic shock hit.
You are in your 18th sprint!?
Considering 2 weeks per sprint, that means 36 weeks nonstop working on the same project. You also comment that work around 6 hours each day. That sounds like a lot!
I don't know that much about agile methodologies (although we're actually using Scrum in our current project), but there's a principle about your working hours (I mean, the amount of time you spend doing a task) should be 60%~70%. Now, doing numbers again, if your labor day is 8 hours long, and you spend 6 hours working, you're really spending around 75% of your labor time. This could be a little deviation that has finally make you have that feeling.
OTOH, I believe that if your project will take long time to be done, sprints should be larger, not 2 weeks, but not a month. Consider a downward curve on your burnout chart: Start your sprint with a regular task burn, and reduce your activity on the last 2 or 3 days before the sprint ends.
Agile is not a stone with the engraving:"work faster/stronger/better/harder", it's more like a blue sky with white clouds that read:"work nice, beautiful more productive". (a little lol at the end courtesy of daft punk + radiohead).
I fully understand what you are saying. For those of you that say "your pace is too fast," I'm not sure I agree that pace is always the problem when people get burned out by this process. Even though keeping track of all your progress IS a good thing, it can also be a stress factor itself (and not keeping track can be as well), not just because your boss/PM will be on you if they see something is not going according to plan, but for yourself. Just having this logged info is something that WILL make most people work just that little bit harder than you normally would ALL THE TIME and I'm not sure putting more time on your time estimates will fix this for everyone. I don't think a motivator (like your burn down chart) is always positive.
Some people won't feel this way, others will. There is not ONE way of work that WILL fit all. Never will be, in my opinion.
Also, if you say that these agile methods and sprints are not becoming more effective/productive, why are you using it at all? Why do you think companies want to use these methods at all? It's not because they are fun....
Effectiveness/productivity always comes at some type of price, in my opinion. It doesn't pop up from nowhere just by using the magic methods (if you get my point).
The only way for you to become more effective (work and pressure-wise) and do less work is make someone else do the work or by automating it.
In my opinion, one should always review ones processes and see what can be automated and spend time on automating your processes instead. Automation comes at the price of doing extra work instead of doing "the real work" but no matter how small the automated task you will always profit in the long run. ALWAYS! If not one day, in two. Not one month, two. Not one year, in two years. You get the idea.
However, I like the idea of having time off to work on personal projects. Most companies will never allow this though. But perhaps you can persuade your employer to get this time to automate your processes and this work could be "outside of sprint control" to allow the time you are talking about to "rest" and get energy back for a new sprint.
Those were just my 2 cents. I get a bit frightened when people say these methods aren't here to make us more effective and work harder. Of course they are! When you have no trace of what you are doing you will rest when your body tells you to. When "everything" you do is traced, you will push yourself. Or I correct myself, most people work this way, some will rest anyway.
Sustainable pace is a key tenet of agile. When doing the management (SCRUM) practices along with the engineering (XP) practices, a team can deliver sprint after sprint indefinitely. However, because one can does not mean one should.
It sounds like you need a change against the endless string of sprints you see ahead of you. A number of options can be offered. Every X number of sprints, a team member (or pair) can rotate off of a team. During your rotation, you can support the run team, take a class, focus on a set of spikes, take vacation etc.
If the team has 5 pairs, and you rotate a person off the line, A person could take an off rotation every 10th sprint (if a single person) or every 5th iteration (if a pair). Issues of budget and return on investment for your activities will need to be addressed by your leadership and or business partner. But clearly, having some time to "sharpen the saw" would bring benefit to the team thus the project. Keeping the team fresh and focused is a very good thing. But we must remember, we are getting paid and we need to bring value for the dollars we earn.
I think you are missing something, but you are not the only one. As Jim Highsmith says: “Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.”
I’d guess that is what is happening to your team. I recommend reading this Highsmith’s IMHO seminal post: Velocity is Killing Agility!
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
Our team is debating whether we want to become Agile or not. None of us are really fluent in Agile. I'd like some thoughts on when Agile works well, and when it doesn't.
To give a little background, we are a small group of developers, six in total. We have far more work that we can handle. Our priorities change often. What is a high priority today, may not be tomorrow. We have many applications to create and maintain. We have started to dabble in Agile practices to the extent that we have daily scrums and two-week Sprint cycles.
If you need more information to answer this, please feel free to ask.
Thanks.
Ralph Stacey's complexity matrix is commonly used to illustrate the sweet spot for Agile:
(source: typepad.com)
For simple projects (where both the requirements and the technologies are well known), the predictability is high so a predictive methodology (waterfall) works well.
For complicated and complex projects (and the vast majority of IT projects are), predictability is low and a predictive methodology won't work, an adaptive approach should be preferred. This is where Agile works well.
When both the requirements and the technologies are unknown, you're close to the chaos and the odds of failure are very high, regardless of the methodology.
I'm speaking only from experience; YMMV.
My team was unsuccessful at making agile work. IMO, it was because:
The very first time the dev team
would hear about a project, it was in
the form of a requirements document
and a deadline.
Stakeholders were often reluctant
to take time to look at the result
of a sprint's work, thus they would not take action between sprints if they thought the project was headed in the wrong direction.
When we showed stakeholders our work,
they generally just OK'd it. They
would talk about what they would
like, to which we would reply "That
can be done in about X amount of
time," to which they would reply,
"Well no need to go over the deadline
for that."
The deployment process was long and
complicated, discouraging frequent
deployments. So in practice, we
often deployed things when a 2-month
project was done, not at the end of a
sprint.
Our sprint planning meetings were
long and inefficient.
It seems everyone was confused about what scrum is (and about what our process was), except for the scrum evangelists.
So I'm pretty sure we were doing it all wrong. Don't you do it wrong, too.
Some things that have sped us up, which we continue to use:
automated builds that work on
everyone's machine (HUGE help!)
a formal arrangement for our code
repository
learning how to apply apply
abstraction mechanisms to UI code
refactoring
unit and integration tests
continuous integration
I guess you could say that our code is more agile, though our methodology is less agile. Whereas before we could not keep pace with demands, now we can.
(I'm not saying agile is bad; I'm just reporting my experience. Also, please understand that I do not choose what methodology we use.)
Reposting a related answer of mine:
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)
It appears your priorities are changing far too frequently for either methodology Agile or Waterfall. With priorities changing frequently, you are likely churning in and out of projects leaving a lot of them partly done. The Agile alway be ready to release may help. It has been my experience that getting a methodology in place will improve productivity.
Your situation reminds me of a project I worked on. The developer on the project asked one question at the start, "Do you want me to be do it right or be responsive?" I was on the project when it was two years into a six month project. One week the same functionality was implemented Monday, Wednesday, and Friday. Tuesday and Thursday were spent removing the functionality.
I would suggest you start adopting practices from Agile. Scheduling a short sprint period could help with changing priorites. It may be easier to maintain priorities for a period of a week or two and may make it easier to stabilize priorities. You will also need a backlog (sounds like you have a large one already).
Management may be more willing to hold off new priorities if you can slot them into a sprint in a week or two. You will also be able to identify the priority tradeoffs. If you add something to the next sprint, what will be removed.
Consider having part of the team working Agile while the others maintain the status quo. Rotate one team member each sprint as you are gaining experience. Consider having the whole team participate in a daily stand up status meeting, and the post sprint review. Once you have demonstrated increased productivity and returns to the company you should be able to increase the amount of work being done using your methodology.
Agile is a adaptive methology. Expect to be making major changes to your methodoly for the new year or two. Eventually, you should reach a stage where you are fine tuning.
In my experience, you absolutely need the following for agile (XP or Scrum at least) to work. Without these prerequisites you are likely to fail. Hard.
Team must be stable and 100% dedicated to this.
Team must be colocated in one workspace.
Customer/product owner must be available on site at all times.
Support from management. This means providing funds and courage to ensure the points above.
Give these points, you can probably tackle anything as long as you keep to the values.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I work in a large outsourcing company based in India. I am in the US and have a team of 3 developers and we are using scrum practices and have had great success with our approach.
My problem is that our company requires us to estimate time on activities monthly whereas we work on weekly iterations. The system provides a list of 45 activities. To give an example of how granular it gets, we have activities like Coding, Coding Review, Coding Rework.
Now everyday we are supposed to enter actual time aginst these activies. And to make things worse the system for time tracking is very poorly designed and is very slow.
The rationale the management has behind this process is that they want to use this time logged to forcast future work. But the problem is that there are no processes in place to ensure that we enter correct time. So we end up putting any numbers and the end of the day.
This is affecting productivity and morale of the team and defeating the whole purpose.
What are you thoughts on Time tracking in an Agile projects?
What are you thoughts on Time tracking in an Agile projects?
100% waste: when asking you to do this, your managers are actually keeping you from working on code which is the only thing that really adds value to the product (not even to mention that the application you have to use is slow, poorly designed so this looks actually closer to 200% waste). This really sounds like outdated command and control to me. This should be handled by the ScrumMaster as an impediment.
Make sure and bring this up as and impendement to your scrum master, also bring it up in your retrospective.
Because you may have to live with it let me suggest two approaches:
Be as accurate as possible and give an estimate at the end of the day.
Write a front end to the clunky reporting system. Figure out and easy to use and time saving interface, write it, then have it feed the clunky old system.
Unless you work in a ROWE, chances are time should be recorded somewhere so that whoever is paying the salary knows where the money was spent. How useful this is and how much it can be used can be debated forever. Evidence-based Scheduling may be the idea that your management has, which has the potential to work and the potential to backfire terribly.
I'd be tempted to see if management would agree to some inbetween timeline here so that the iterations and planning align. The problem with trying to plan 3-4 weeks down the road is that what happens in the next 1-2 weeks can dramatically impact that. My suggestion would be to see if a 2-week timeline could be agreed so that almost a half-month is planned at a time. It is a bit of a compromise but assumes that whatever system the monthly data goes into would accept something biweekly. An alternative would be to do monthly iterations though that may cause some upheaval I'd imagine.
Time tracking can be useful if there is trust, honesty, and most everyone is respectful about the information. This can be asking a lot as I'd imagine many have been burned by such systems. Does management know of the slowness and poor design of the time tracking? For example, if it is taking an hour a day to log all the time and you can explain why that really is the case, there may be an opportunity to get a better system. A key point here is to know what specifically are the problems, why they are problems and what kinds of suggestions could be made as while I'd say that time should be tracked, one could use spread sheets for a relatively low-tech way that may not be great for management, but part of this is accepting trade-offs, IMO.
Sounds like the time tracking is probably a bit too granular, or too rigid in its entry. What if, instead of having you enter time for each category at the end of the day, they instead asked you to keep a log that you could fill out with what you were currently doing during the day - so you'd get something like this:
8:30am - 9:45am: Coding
9:45am - 10:00am: Coding Review
et cetera.
This is a tough one. The problem is that the time used will NOT forecast future work. That's very well documented and a dangerous trap many fall into. Velocity can help to forecast future work but it obscures the hours by design.
The problem with the approach is this: Not all hours are alike. Capturing hours turns work into "ideal" time. Future work is the estimated not by the team that is doing the work (and no 2 teams are alike), but by management that has used those hours to come up with some algorithm. Sound familiar? It's not Scrum or Agile. Management neither understands the process of Scrum nor has bought into it.
Having that confusion is not good. Clients believe you are providing something you are not, team members work under false assumptions, and management is not there to provide the support you truly need.
So, it really won't matter what you put down for hours... very likely the process will fall back into a non-agile approach which will be statistically as accurate as just making up hours and reporting them randomly. At the risk of sounding ridiculous, you might as well save your time and just make up hours.
Now, if time is used to see how much you spend doing interviews, that's easy to gauge without a tracking system.
If the time is used for billing, that's a different story. That's not Scrum-related, but a part of business process.
I was in a formal testing class, and the lecturer was trying really hard to convince one of the student to use timesheet to track time, because the entire software engineering/project management theory is based on that time sheet to do linear projection.
The problem is the reality is nonlinear (depends on the level volatility of the project)
Agile process like scrum focus on people not process, but how about people and business.
because we mentioned that tracking time was using for billing customer. the problem with tracking time is it may hurt people. for example, you estimate task and do it 10 day, next time you do the similar task and now with 10 days you cannot do it because of some unpredictable reasons, even your scrum master or PO can understand and share with your the feeling of missing the deadline(not entirely your fault)...BUT how about others behind that layer, top managers, other project managers, other developers...they may read it wrong that you had issue with your performance....so for me tracking time should be fine if we have a way to do it completely behind the developers and we then use that data to analyse the root cause and feedback for the team to learn from it. the tricky part is doing without creating bad feeling for the people which I still cannot find any workplace can do this well except rumor said that Google is the place with their fancy style.
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 7 years ago.
Improve this question
I have met a lot of people for whom Agile has worked really well, and most of them tend to be managers and architects who plan and delegate the work. However I really haven't found much good developers convinced that Agile is working for them.
Of course you can say if Agile isn't working for you, you aren't doing it right. But whatever remixes of Agile are out there, is it working for you as a Developer? And why? Does anyone else think, within a traditional (or close to) team structure, Agile feels more like a form of micromanagement than self-management?
At my first job, we had daily scrums, wrote automated tests, had automated builds, pair programmed, etc. We had been in the agile groove for several years. And for our efforts, we were rewarded with software that I wouldn't touch with 20ft pole. The quality of our product was atrocious: I'd describe as the piecemeal hacking of 100 amateur developers.
What went wrong:
The company I worked at had a notorious reputation for hiring entry-level developers for the lowest pay ($25-27K/yr was the norm), and frequently we'd outsource work to the lowest offshore bidder. I've heard that agile just doesn't work on inexperienced developers, and I think it showed through the code and our turnover rate.
No documentation of any sort. No functional documentation, no technical documentation, no requirements, no bug tracking. No one ever wrote things down on persistent media: all requirements and bugs were communicated by email, word of mouth, and psychic mindreading.
Lousy testing: our automated tests were invaluable, but QA and UAT testing was a disaster. Since we didn't have any formal requirements documentation, QA users didn't know what new functionality they were testing, so all QA consisted more or less of haphazard end-to-end testing. User acceptance testing was performed in production: we installed the product on our customers servers and reported bugs as they occurred in production.
Crisis-driven development: bugs were handled by using the "OMG WE HAVE TO FIX THIS AND REDEPLOY PRONTO! NOW NOW NOW! NO TIME FOR TESTING JUST FIX IT!" management methodology.
Although we did everything right and really adhered to agile principles by the book, the methodology failed harder than anything else I've ever seen.
In contrast, the company that I work for now uses a waterfall-like methodology, produces a few hundred pages of documentation for each project, has few automated tests but a sizable QA team. Interestingly, the quality of our product is through the roof, and the work environment is orders of magnitude above and beyond the other company.
I know many people have had the opposite experience. As is usually the case, methodologies are not a golden hammer --- you can probably start a successful project no matter what methodology you choose. In my experience on successful and unsuccessful projects, I get the feeling that methodology doesn't matter as much as environment: comfortable, happy developers and sane project managers are all it takes make a project work.
At my company, we made a wholesale switch to agile practices about 4 years ago when a new VP came in. This VP had experienced success with Agile in the past, and decided it was what we needed.
As it turns out, he was right. I was a developer at the time (albeit a somewhat junior one), and I loved the practices. Pair programming really aided knowledge transfer and prevented the formation of knowledge silos. Unit testing, test driven development, and test emphasis in general made for more robust code that wasn't over-engineered. No Big Design Up Front meant that instead of spending 6 months writing requirements documents (by which time the market had passed us by), we were prototyping and delivering real value to customers in a timely matter. Working closely with a customer surrogate (in our case, a technical product manager) greatly shortened cycle feedback time, which helped us deliver what the customer actually wanted.
Our organization had quite a few talented developers, but we were very prone to cowboy coding. A few developers didn't like the new practices ("What do you mean, write tests? I'm a developer!"), but generally everyone loved the changes. Defect rates went down, customer satisfaction rates went up, and our office became very well regarded in our company.
About a year ago I became a manager, and I heavily use Agile practices, incorporating some Lean principles as well (value stream analysis, waste elimination, kanban). Tightening up release cycles has been an ongoing activity, and my team now releases as often as possible (with quality!) - often every two weeks. We have no field reported defects from my team in the past year, and the sales people and product management love the shorter release cycles.
As a developer, Agile really increased my confidence in working with various areas of code (I now feel nervous whenever I'm changing anything in a package that DOESN'T have 100% unit test coverage!), taught me to be a more well-rounded programmer (thinking of test implications, business impacts, etc.), and helped me write simple, self-documenting code. As a manager, Agile and kanban gives me predictability, lower lead times, lower defect rates, and an empowered team. This is not theory, or speculation, or hand waving - our team morale, defect rate, customer satisfaction, and balance sheet have proven that Agile can do wonderful things for an organization.
To comment on the Principles of the Agile Manifesto from my experience at a site that tried it.
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
This was a double-edged sword for my last site -- valuable was taken to mean 100% perfect and bug-free.
Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage.
I still communicate with that site and just today, their rock-hard deadline date, they were given a requirement change. That was just the way things were there; it's almost as if they wanted failure.
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale.
The norm for many years was basically build and deploy daily, hourly, near real-time...
Business people and developers must
work together daily throughout the
project.
Some of the meetings/reviews with respect to this were hilarious. We were reprimanded for not working with the people (because they asked us not to because they were already working 9-10 hour days) and then for bothering them because they were busy.
Build projects around motivated
individuals. Give them the
environment and support they need,
and trust them to get the job done.
Ahh, here's our problem... We had top-of-the-line PCs but the business side wasn't supportive. The positive morale essentially got beaten out of you after about a year or so... This also negates your micromanagement concern (if implemented correctly).
The most efficient and effective
method of conveying information to
and within a development team is
face-to-face conversation.
This worked out well. Personally I prefer email because I hate taking notes.
Working software is the primary
measure of progress.
No doubt here.
Agile processes promote sustainable
development. The sponsors,
developers, and users should be able
to maintain a constant pace
indefinitely.
I agree with this 100%; the problem with the last business team I worked with was the expectation of 30-hour days, 10-day weeks, and 400-day years was not a pace I agreed with.
Continuous attention to technical
excellence and good design enhances
agility.
This is where some developer morale & education was needed.
Simplicity--the art of maximizing the
amount of work not done--is
essential.
I love this one and it's long been one of my goals. However, there was a "if you're not typing, you're not working" attitude that was tough to overcome.
The best architectures, requirements,
and designs emerge from
self-organizing teams.
I agree with this about 90% -- my only caveat is that they must be well-educated and well-informed teams.
At regular intervals, the team
reflects on how to become more
effective, then tunes and adjusts its
behavior accordingly.
We just failed here and it likely caused a lot of other problems we had. The business side was really good at saying "you need to do what we say needs to be done."
To wrap it up, if you're working somewhere where everyone is informed and on board with an Agile methodology, it should be a great place to work. When the goal is great software, momentum alone will carry any project.
Agile has worked awesomely for me as a Developer in my current environment. Here are some practices and why it seems to work so well:
Pair programming - This prevents anyone from feeling an individual ownership of the code. Pairs of developers tend to make better code than one person's "mad science" code that seems to happen if one person writes a bunch of code in isolation. This also allows for someone else to be brought in if someone goes away and that feature or enhancement has to get done while the person is away. Sometimes, one developer may think something will be great but if no one else can understand the code, it is useless to have unless it is perfect and futureproof which isn't likely.
Scrum - This creates both an accountability and communication so that each person knows what the other is doing. If someone wants to know how the sprint is going, just show up at the stand up. The standup is really simple in that it is just 3 questions: What did I do yesterday, what I am doing today and what would prevent me from getting that done?
Test-driven development - A variation on this is practiced where I work in that we generally try to have tests for most of the plumbing code we are writing to customize a CMS in the big project we are doing. This mindset can be tricky to get into though it does get easier as one practices it more.
YAGNI - The "You Aren't Gonna Need It" principle that can really be hard if you've been a perceptive programmer that generally puts in 101 things as a "Well, I might need this someday..." mindset. Another way to put this is a "Keep It Simple, Stupid" idea.
Sprints - The idea here just seems to prevent a sense of being overwhelmed as we are just working for 2 weeks on this or that, and don't look too far forward as it may well change.
Demos - Showing off what we have done, getting feedback on what is good and what isn't is crucial for getting things better and having a mindset that we want "continuous improvement" in the project and what is good enough today, won't be good enough tomorrow and get better at what we do.
IPM, Retrospectives - The ability to look back at what was done in retrospectives is useful for venting frustrations, celebrating things working well and finding ways to address pain points. IPM is where we determine our future for the next sprint in terms of what will be the goals and how long do we think various things will take by using a couple of different estimation tools, one for points on "epics" as we call them and the other for hours on an individual task or card which is part of a story that is something between the epic and a small piece of work.
Storywall and user stories - Now this low tech tool since it is just a few whiteboards, with dividers and post its provides some structure to things. We have lanes for each of the epics and various columns for states of work: Backlog, in development, on dev, or on test. There are also places for the task backlog, blocked cards, questions, standards and practices and a few other things that may be useful for managers to see to get an overview on the current status if they want more of a bigger picture than what they would get at standup.
Broken windows/technical debt/tasks - These are similar in some respects and are useful as a way to illustrate that quality matters,i.e. we don't want broken windows that can be easily explained in non-technical terms by either using a house in a neighbourhood or the New York Subway sytem as starting points. Technical debt being something that doesn't immediately add business value that is sometimes an important thing to use to prevent some problems as there may be problems with a particular architecture and so part of a sprint may be spent doing a re-arch that has to be communicated so that if there is a sprint with little to demo this is why.
I don't know if the idea of a "self-organizing" or "self-managing" team is part of Agile, but it has been a bit of a challenge for me to have enough faith and trust in my co-workers that things will work out fine. The professionals that are the rest of my team know what has to be done, are reasonable, honest people with integrity to just get the work done and not be jerks about getting things done. There aren't egos or bad attitudes which really do help foster building a team.
Agile hasn't worked for me, the main reason being that the systems I usually develop need a well-defined and well-thought architecture, which is hardly realisable by an agile approach. Agile approaches tend to write as little code as necessary to pass the applicable tests, and thus to grow the system organically. This can be nice from many perspectives, but it wreaks havoc from the architectural viewpoint.
From my personal experience, Agile methodology tends to create a huge technical debt in the long term, and while it might save you (as a business owner/management) a couple of bucks short term, in the long term it will come back and bite you. Whatever you do not fix now will eventually cost you many hours of work to fix at a much higher cost than it would have cost you to invest some more hours into the original problem.
Agile is always great from the point of view of beginners and management, but I do not know one experienced programmer who actually loves it. The whole point of Agile is to save development money for a company, it has nothing to do with actual product quality. In fact most of the methodology promotes bad code done quick over well-engineered code. The difference is that a few years down the road, you have to do the whole work all over again whereas the well-engineered code can last decades without corrections. Good programmers do not need Agile methodology most of the time.
We have a business logic library written 22 years ago here by a single team of 3 programmers using waterfall methodology, and that code hasn't needed a single correction since. Because it was tought properly, was well-engineered, and the three programmers took their time and were careful with their implementation. Agile methodology would instead ask of those three to do the strict minimum to make sure some ill-defined tests passed, and then wait until the next time you hit a wall to add some more duct tape code. It's a ridiculous way to work and goes against every engineer fiber in my body.
To this day I refuse to work in an Agile environment, because frankly I do not need it, and I do not need an employer who thinks I do need it.
Agile is not a methodology, it is a subset of methodologies that have a common set of goals, and more often then not those methodologies have wildly varying results based on team makeup, corporate culture, and implementation.
Off the top of my head, purely developer agile practices would include pair programming, TDD, user stories over specs, the assumption that all code is going to be refactored several times (although this is part of TDD) and code reviews more then anything. Things that impact us are daily standups, being engaged with users regularly and directly, postmortem introspections, and very tight development cycles.
I'm a developer and a manager at the same time, so I either have special insight or my opinion is totally invalid. ;)
I will say that Agile means a lot of things. It's actually a whole family of methodologies and guidelines at this point.
Exposing yourself to all these interesting ideas is really the thing. As a manager, it's very hard for me to decree that a whole team suddenly adopt a whole methodology, but if they see me constantly trying to improve every aspect of my game, I think they appreciate that. And hopefully, if they like what they see, they follow my example.
I've managed to slowly implement a bunch of things from Scrum without (hopefully) coming off as a tool. Burn down reports, stand-up meetings, and story cards on the whiteboard have really made us better at shipping software. For instance, on any project tasks are constantly being done ahead of schedule or late. In a really big project, it can become very difficult to tell what that's doing to your ship date. With burn down reports, I can tell what a slip does to our ship date, and if we need to just start cutting features in order to meet a deadline.
That's more of a management thing, but the other devs here care about it because it might mean they get to keep their jobs or avoid a death march. :)
But it's not just management stuff. There's tons in Agile about best practices for source control, unit testing, etc. Just good solid best practices. As an industry, we are pretty terrible about mentoring, so it's good that this information is out there.
From the developers perspective I think it works well. In my point of view agile techniques have in common that the loop between defining the task, working on the task and getting feedback from that task is a very small one as compared to a non-agile approaches.
Take TDD as an example: Code the test, red bar, code the functionality, green bar, refactor, red bar, fix, green bar.
From the managers perspective this faster feedback loop is also true: Daily meeting one, status green, daily meeting two, status yellow, countermeasures / re-assign ressources, daily meeting three, status green.
Immediate feedback and knowing where you are heading gives a feeling of safety.
In the so called 'traditional team', Agile development would increase the visibility of individual developers to management. That would probably allow managers and architects to plan their work better. Ofcourse that could be interpreted as micromanagement.
But from an organizational perspective, if it produces results, who cares.
I guess what makes an "agile" project agile, is the methodology: "Design for today not for tomorrow".
For any not life-critical software systems this is a way to keep programmers coding in stead of discussing ages about design. Please note that design is not scrapped, it is just done in smaller and therefore more overseeable chunks.
All other techniques that are associated with agile, like pair programming, are more borrowed ideas that could also be used effectively in any other methodology.
Now, does this technique 'work'? Yes! If applied correctly, the technique promotes that the software product will be ready for shipping at any time to react to competition.
On the other hand, because programmers are feeling they are coding more, they are generally happier. And they are less irritated by writing specs because this phase is inherently always small.
But again, if you know exactly what your product is going to be and especially if it is life-critical like the space shuttle, agile development is not what you want.
Nearly every management is aware of "Agile" by now: It's this thing, you know? Alone by your initial question I would assume that something is really going wrong. I really recommend you reading a book like Practices of an Agile Developer (as the title suggests - it's about what's in for you).
Some managers read a book and then will know what agile is all about. They are telling you what to do and everything is fine, isn't it?
If you look around, there are a lot of developers (in Agile companies) who can't tell you within a second what the purpose of a stand-up is - and that's an issue. If you (and maybe even nobody else) don't know the why the StandUp won't make things better.
Take a look at time tracking (and time estimation) - there are some managers who think it's about measuring how much work you do: Hey, you have a 40h contract but the time tracking tool says that you have only be working for 38h this week! That's not how it was meant to be used.
The only thing you can do about that: you need to learn what agile methods are out there. Mediocre managers will pick the ones they find interesting. Good managers will grasp the why and not only choose the methods for their direct benefit - but also those which will make the team more happy / efficient / teamish (Team vs Workgroup).
P.S. Something you really need to take care of: In agile there is no place for slackers. Everybody has to do stuff on their own. You have to put personal interest into the success of the product. If you don't do things on your own, somebody will tell you what to do (and then there's micromanagement).
Has Agile really worked? "Yes."
Before there was "Agile Programming" there were equivalent largely unrecognized methodologies. I thought these were called incremental prototyping but apparently this has been split into that and evolutionary prototyping.
I suspect that many or most of the successful systems were so constructed. Just because the methodology grew a new name doesn't mean that it suddenly appeared.
It's just that Waterfall and other broken management techniques that got all the press.
I say Agile works.
I say it's the only thing that ever worked.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm starting up a personal project to develop some open source software. I want to use Scrum as the PM process on this (as I like the Product Backlog, prioritisation, and if I can get them, the burndowns) but it seems to me that I won't get the full value because I can't at the outset guarantee the amount of time myself and my collaborators will be able to commit to work during a given sprint.
I know there are other benefits that I will still get from using Scrum but are there variations or tricks and techniques I am unaware of which will enable me to get the value of things like burndown charts and timeboxed iterations? Or am I just being too hopeful?
TIA.
Regs, Andrew
As this is a hobby project, are you actually concerned about deadlines? How much value would it in fact give you to know how much will be done after a Sprint?
If your answers are no, you might want to look at a kanban approach as an alternative.
I think about agility in software development and come back to three aspects which provide real utility:
A known backlog of tasks to do
A regular opportunity to openly discuss the current status of tasks being addressed and hurdles to overcome
Team-managed iterations that result in a working subset of the eventual full product
In a work environment, say my 9 to 5, it is easy enough to adopt such a methodology. You've got devs who will be there at least 40 hours a week, every week and so there are few barriers to engaging in an agile practice, like Scrum.
In "after hours" settings, commitment levels of participants often vary. That's life. So you work with what you've got. If Matt is excited about the project but his schedule is busy and the number of hours he can dedicate to the project will fluctuate a bit, so what? If he's "on board" and serious about the time he is willing to invest in the project, then it is just a manner of planning your iterations accordingly.
I personally wouldn't get wrapped around the axle about this, though. In the end, Scrum or any 'agile' process that you adopt should be a means to an end, not the end itself. Particularly in an environment where conditions will differ from those in the 9-5 world, you need to be flexible in your iteration plans. You still plan your work and work you plan and engage in the regular communication and the "where are we today?" exercise to keep everyone in the loop.
The goal is solid software - if you can't get a lot of utility out of a particular aspect of Scrum, or any process, so what? You'll likely develop a hybrid process anyhow. I wouldn't get too too concerned about getting things like burndown charts and velocity and all that. I honestly think the focus needs to be more on quality software being developed and less on the artifacts that might help down the road in the next iteration or the one after that. That's my opinion though.
My advice is to use the things that work and keep it simple. Backlogs are great and the daily 'meeting' to touch base with everyone - even if this is a virtual one done by IM - is where the real value is found. Hobby or side jobs are tough things to commit to and I wish you well with it. But be open to the fact that it might not work as well as the process would at the 9 to 5.
In a by the book setting you won't use real time for calculation of the burndown chart but rather story points. After a few sprint you will see an average velocity and thus be able to generate a burndown chart and use this velocity for commiting to the sprint items.
And I strongly disagree with warrens post on the scale-down point. The main problem I see is a strongly varying velocity between two sprints, since it is only a hobby.
When the amount of time the Team is able to put in at every iteration varies too much, the velocity cannot really help to plan the Sprints since it will vary too, especially at the beginning. However, the average velocity may start to stabilize after several Sprints.
Nevertheless the burndown charts will be useful still as they show an accurate status of the current iteration.
You'll also take advantage of the estimations "calibration" Agile processes bring.
The problem with Scrum for this sort of project is more around the type of development team structure that Scrum is designed to support, in particular the colocation of the team for the daily standup meetings. Its hard to have a daily standup meeting when you aren't at the same physical location. In addition, I doubt you will have a Product Owner on your team, and you will be both the Scrum Master and a developer. On top of this you and your other developers will be working at different times and days may go by without any work being done at all. This may make coordination of the team difficult.
Every project, regardless of develoment methodology, should have a good idea of what needs to be done (the product backlog), what needs to be done shortly (the sprint backlog), and how long it will take to do these tasks so you have a reasonable estimation of how long the project will take (the project velocity and burndown). It is the other parts of Scrum that you may have problems with - not being colocated for meetings, the lack of a Product Owner, using a notice board to show the sprint status, etc.
This is not to say you can't modify the Scrum process to suit your purposes. For example:
have video conferences/Skype calls/IM meetings at prescribed times several times a week even if nothing has been done. Daily is probably too often for this type of project but maybe three times per week would work for your team.
use a web based issue management system so you can all see the product backlog, know what the sprint backlog is, and know what people are working on
have set sprint lengths (say, 3-4 weeks) so that the developers can sense the momentum and know the deadlines
understand what time is being spent on development so you can work out your project velocity and what can be acheived in the next sprint. This may be hard as available time will vary from sprint to sprint.
have retrospectives after each sprint so you can tune your development process with respect to what went well and what didn't. This would be the ideal time to meet at the same physical location if possible.
Scrum, at its essence, is mostly about effective communication so if you get that right you should be able to make a modified version of it work for you. Just remember that communication reduces in effectiveness down the list of
In person
Video conference
Skype/phone/voice calls
Instant messenger
Email
so try to use the most effective method at your disposal for your meetings.
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 been using Scrum for around 9 months and it has largely been successful. However our burndown charts rarely look like the 'model' charts, instead resembling more of a terrifying rollercoaster ride with some vomit inducing climbs and drops.
To try and combat this we are spending more time before the sprint prototyping and designing but we still seem to discover much more work during the sprint than initially thought. Note: By this I mean the work required to meet the backlog is more involved than first thought rather than we have identified new items for the backlog.
Is this a common problem with Scrum and does anyone have any tips to help smooth the ride?
I should point out that most of our development work is not greenfield, so we are maintaining functionality in an existing large and complex application. Is scrum less suited to this type of development simply because you don't know what problems the existing code is going to throw up?
Just how much time should we be spending before the sprint starts working out the detail of the development?
UPDATE: We are having more success and a smoother ride now. This is largely because we have taken a more pessimistic view when estimating which is giving us more breathing space to deal with things when they dont go to plan. You could say its allowing us to be more 'agile'. We are also trying to change the perception that the burn down chart is some kind of schedule rather than an indication of scope v resources.
Some tips on smoothing things out.
1) As others have said - try and break down the tasks into smaller chunks. The more obvious way of doing this is to try and break down the technical tasks in greater detail. Where possible I'd encourage you to talk to the product owner and see if you can reduce scope or "thin" the story instead. I find the latter more effective. Juggling priorities and estimates is easier if both team and product owner understand what's being discussed.
My general rule of thumb is any estimate bigger than half an ideal day is probably wrong :-)
2) Try doing shorter sprints. If you're doing one month sprints - try two weeks. If you're doing two weeks - try one.
It acts a limiter on story size - encouraging the product owner and the team to work on smaller stories that are easier to estimate accurately
You get feedback more often about your estimates - and it's easier to see the connections between the decisions you made at the start of the sprint and what actually happened
Everything gets better with practice :-)
3) Use the stand ups and retrospectives to look a bit more at the reasons for the ups and downs. Is it when you spend time with particular areas of the code base? Is it caused by folk misunderstanding the product owner? Random emergencies that take development time away from the team? Once you have more of an understanding where ups and downs are coming from you can often address those problems specifically. Again - shorter sprints can help make this more obvious.
4) Believe your history. You probably know this one... but I'll say it anyway :-) If fiddling with that ghastly legacy Foo package took 3 x longer than you thought it would last sprint - then it will also take 3 x as long as you think the next sprint. No matter how much more effective you think you'll be this time ;-) Trust the history and use things like Yesterday's Weather to guide your estimates in the next spring.
Hope this helps!
I am happy to hear that scrum has been largely successful for you - that is more important than having the sprint burndown chart look ideal. The sprint burndown is just a tool for the team to help it know if it is on track for the sprint goals. if the team has been meeting the sprint goals, I would not worry too much that the chart looks like a roller coaster. A few suggestions
During the sprint retrospective ask the team where the additional work is coming from
Extra work can come from not having good acceptance tests early in the sprint
Extra work can come from not having a well groomed backlog. A good rule of thumb is to spend at least 5% of the team's time thinking about the next sprint's stories ahead of time.
Monitor work in progress - is the team doing too much in parallel?
During sprint planning - how does the team feel about the breakdown of tasks that make up the stories?
If you have not been meeting sprint goals - use the established team velocity to take on less during the next sprint. You have to get good at walking before you can run.
In my experience, Scrum is definitely geared more towards new development than it is towards maintenance. New development is much more predictable than maintaining an old, large code base.
With that said, one possible problem is that you're not breaking up the tasks into small enough chunks. A common problem people have with software planning in general is that they think "oh, this task should take me 2 days" without really thinking about what goes into doing that task. Often, you'll find that if you sit down and think about it that task consists of doing A, B, C, and D and winds up being more than 2 days of work.
As others have said, I would expect a burndown to be up and down. Stuff happens! You should use the "up and down" bits as fodder for your retrospectives.
Make sure everyone is clear on what "being done" means, and use that joint understanding to help drive your planning sessions. Often having a list of what constitutes done available will (a) help you remember things you might forget and (b) will likely trigger more ideas for tasks that would otherwise surface later on.
One other point to think about - if you are working month on month with an unpredictable codebase, I would still expect your velocity to normalise out to a reasonably steady rate. Just track your success against your planned work and only use completed items as a maximum when planning. Then focus on your unplanned tasks and see if there are any patterns that suggest there are things you can do differently to include those things in the planned work.
I have had similar issues. My previous team (on it for over a year) was large and we maintained a very large, rapidly changing codebase for series of initial product launches. Our burndowns were shameful looking, but it was the best we could ever do.
One thing that may help (make your graph look better) is stick to the number of hours/points committed to constant. If you have underestimated a task, and have to double hours, pull something out of the sprint. If you pull in a new task, it's obviously of higher priority than something your team committed to so pull that other thing out.
We tried the breaking up the task into many tasks in and before planning, and that never seemed to help. In fact, it just gave us more damn tickets to keep track of during the sprint. Requirements started migrating to the tickets and (not surprisingly) got lost in all the shuffle.
On my new team we took a pretty radical approach and started creating big tickets (some over a week long) that say things like "implement v1.2 features in ProjectX." The requirements/feature lists for ProjectX (version 1.2 included) are kept on a wiki so the ticket is very clean and only tracks the work performed. This has helped us a lot - we have way fewer tickets to keep track of, and have been able to finish all our sprints even though we keep getting pulled off our sprint tasks to help other teams or put out fires.
We continue to push items out of the sprint if (and only if) we are forced (by the man) to bring in new items.
Another simple tip that helped us: add "total hours in sprint" to your burndown. This should be the sum of all estimates. Working on keeping this line flat may help, and increases visibility of the problems your team may be facing (assuming that won't get you demoted...)
-ab
I had similar problems in my burndown as well. I "fixed" it by refining what was included in the burndown.
SiKeep commented:
Its progress against the backlog
selected for that sprint, which may or
may not end up as a release.
Since you selected certain things for the sprint and that's what is on the burndown, I don't know that all the "new work" should appear in the burndown. I would see it going onto the backlog (not affecting the burndown), unless it's important enough to move into your current sprint (which would then show up as an upward trend in the burndown).
That said, minor up's and down's are normal, if the trendline basically follows your expected velocity. I would be concerned about the roller-coaster trend you're mentioning. However, the idea of isolating the burndown by only adding high priority items to the current sprint may help dampen these up and downs on your burndown.
As others have said, the planning before the sprint starts should be short...(no more than 4 hours).
We are using a 'time-boxed' task for unplanned tasks. Whenever high-priority work is coming, or sudden bugs pop up, we can use time of the time-box (but, we can never go under zero).
This method has the additional advantage that we can easily track which tasks were unforeseen, and keep those things into account during our next sprint planning.
You can integrate the new work at the sprint's start date, to have a great looking Burndown chart.
You can tag with a specific marker the additional work and evaluate at the sprint's end why you haven't be able to identify those tasks before.
We are now using a burn UP chart. Instead of just charting the amount of work left we chart two things: the amount of work completed and the total amount of work (ie. completed + outstanding).
This gives you two lines on the graph that should meet when all the work is done. It also has a big advantage in that it clearly shows when progress is slow because more work has been added.
If you like, the PO 'owns' one line (the total work) and the developers/testers 'own' the other line (work done).
The PO's line will go up and down as they add/remove work.
The dev/tester line will only go up as they complete work.
Article Is it your burn down chart? explains what given status in burn down chart means. It also provides suggestions what to do with that.
Some examples described in the article:
This is as it should be. If your burndown chart looks like the model chart, you're in trouble. The chart will help to see if you will be able to make you commitment and finish all the stories.
Discovering stories during the sprint will always happen. Ideally you would be able to design and find out the tasks up front but if they worked why would a big upfront design not work?
To answer you last question, the sprint planning should take at most four hours.