DFW Scrum Message Board › painful beginnings
I'm feeling a bit discouraged.
In my industry (healthcare) quality is job #1 and requests to modify our application come in at a mind blowing rate.
That said, we found that the standard waterfall methodology left everyone frustrated (developers, testers, customers, executives). So we got the green light from executive management to try something new...Agile.
So we started off with one segregated agile team that was split off from the rest.
To say I have found the process to be enlightening is an understatement. Many issues of quality and developer skill deficiencies have been uncovered that previously went unnoticed due to "all the background noise" of our old system.
That said, I think the developers have found it incredibly stressful. So my question is why?
We have had 3 sprints, totaling 37 days in all (10, 12, 15). We take a full day for Sprint planning (8 hours).
As with the previous sprints, on the last one...
They came up with the tasks lists.
They came up with the task estimated time.
We started with 6 hour workday and assumed 80% of that would be planned.
So in a 3 week sprint, the 2 developers committed to 144 hours. (I'm excluding the work for the tester that was on the team)
They were undisturbed by the normal chaos in the department. Their priorities were not constantly changed (like the waterfall team). They were coding a new module from scratch (so they weren't dealing with the normal issue of having to first understand someone else's code before modification).
In the end, they only completed 109 of the planned 144 hours.
Yet, they complain they are exhausted. I don't understand how anyone could complain about being asked to complete 109 hours when they are given 240 hours uninterrupted to do it in.
Granted we had a snow storm in the middle of a sprint...and one developer struggled with a hard-drive failure for a day and a half....but all-in-all, the problem in my eyes is defects. My reaction? I'd be exhausted too if I coded that many defects and was forced to fix them myself!!
I think our waterfall team may have many of the same issues its just more obscured by the fact that they throw their code over the wall to the testers and have 9 more weeks to fix the little buggies that trickle back (turn around time for a persons defects is much slower and the bugs are handled by the team at large instead of the person responsible fore coding the bug).
One agile developer complained that he liked the old waterfall because he could code for a while and then visit with people, then go back to coding.....I agree they could, but then again the waterfall team work 10-12 hours a day. Its a trade off.
Are there some people that are just not cut out for agile, personality-wise?
Are we being too optimistic in our velocity estimates?
I have informed my director that I should not be scrum master. The reason is because I am the application expert and also the development team manager, and I think the developers were not able to separate my old role from scrum master and it caused them undue stress. I also know that our product owner was woefully inadequate (but wanted the glory of rolling out this process).
That said, my director sees the entire thing as a success on many levels. I don't share her enthusiasm but maybe I should?
Does any of this sound like normal growing pains when moving to agile?
My team (ranging from 15-20 developers) has worked overtime for almost 5 years, with priorities that change DAILY based on customer whim... I was hoping to get them to a more stable environment like agile. But I'm not sure if they can stand the discipline that it requires.
Any suggestions? Advice?
I read this quickly. What you are describing are patterns that we often run into with new teams.
I would be happy to chat with you about it, but will add a quick response.
First of all moving to Scrum exposes messes! This is good news! While it is a simple framework it takes time to inspect and adapt.
On your time on task allocation, your capacity I generally coach teams to reduce their capacity for time on tasks on initial sprints. This will give the team a feel for what is sustainable for high quality work.
The capacity number is not time sheet time, but a number to help you as a team determine if you can take on the work given your capacity. Most teams over-commit during the first sprints. They are not used to thinking about their tasks and new tasks always emerge.
Does your team think that their biggest struggle was defects? Is that was discovered in your retrospective? Did they come up with an action plan to pull quality forward?
I am wondering if you had the same number of defects on your waterfall projects were similar and they just didnt see them right away. There are several patterns that be at cause. My first reaction would be to ask yourselves 1. Are your stories too big? 2. Are we "swarming" our stories or are they all being worked on at the same time and dumped over to QA? (mini waterfall) 3. Are the QA people working with the developer people at the beginning of the work on the story? 4. Are they pairing? 5. Are the code reviewing as they go? 6. Are they testing as they go?
The question about who should be the ScrumMaster, the SM's role is one of servant leadership, to help the team move forward and remove obstacles. Chief communicator, facilitator vs. telling the team what to do. The transition from a more traditional role to SM can take time.
I would also encourage you to find bright spots and celebrate your successes. I am glad to hear the director is seeing the positive and that doesnt mean you shouldnt strive to get to a happier place.
If you want to chat I would be happy to. I have some time this week. My work email address is email@example.com
Hope that helps,
Flower Mound, TX
Those are wise words from Julie. I would add only a few things.
* I'd say it's unusual for a Dev. Manager to also be a ScrumMaster but there's no reason it can't work. It depends, do you have the time for the role and do you have the skills and desire for the role. If not then find someone else to do it.
* As Julie said it's usual for a new Scrum/Agile team to experience "growing pains" especially in the early Iterations. This should solved in Retrospectives. You didn't mention Retrospectives. Are you holding them? If not then it is recommended for you to start doing this as it's a very valuable use of time. Retro's are where we talk about areas needed for improvement. The Developers may say "Gee, that last Iteration was very stressful." Then we talk about why it was stressful and what we need to change to make it not as stressful the next Iteration.
* Ah, the "is this person just not suited for Agile development" question. The disciplines of Agile, especially the time-boxed nature of the Iterations, put more focus on what the team is doing than traditional Waterfall. Some people prefer the nature of Waterfall but what we have learned is that Waterfall hides to many things, it usually results in overtime and death-marches and it concentrates on creating the planned product instead of the right product. If you are making a transition to Agile then everyone has to make the transition. You will need to handle the exception of team members who chose not to work in the new way on a case by case basis. I've seen very few techies who can't make the switch. About personalities, one thing we say in Agile is that Agile cannot handle massive ego's because Agile is a team effort.
* My guess is that probably 1) your Velocity is too high and 2) your team may be to lean in your task hours estimates. Try backing off on your Velocity an bit because you can always add in another Story if you are trending to finish early. And have your Developers give a little more breathing room to their task estimates.
|Charles Gary M.||
Michelle, thanks a mil for sharing this. Julie and Dave's replies are great, and it makes me proud that our crew is so wise.
I'd like to bring this to the larger group, if you are willing? Maybe this month we can "check in" on where you and the team are in this journey, eh?