During my wellcomed sweet holidays I kept connected to my fellow agile communities to read what is happening during my “Summer Sprint”. One of the threads was very interesting and I thought that I have to share it with you.
The theme is double overlapping: on one hand you find “buging the bug”, it’s about managing bugs in an agile product development. In second hand, you have “scaling the agile evil which is about agile project escalation in a traditional organization.
And if you add both bullet points, you find the theme on scaling agile projects when the house is full of bugs! So, I reduce the scope on this.
Let’s start the story. For correctness, I will hide every details that could affect my customer but I know he will recognize “it”self. To make this post a bit more interesting, let’s call “him” Joe.
I have a project...and I’m lost!
Joe send me an email to ask on advice for his project. This is a big project where bug-fixing takes a major part.
To handle this he researched different options to integrate all stakeholder’s requests. The issue was to be the most reactive to fix the bugs (some of them needing to be handled in 2 days max) and to control the chaos they certainly will create without stopping the Sprints.
He checked some practices like firefighter teams, bug treatment as an user story in the Sprint Backlog (only non-bloking one), and Kanban.
Kanban sounds perfectly fitted to his aim. The strategy he wants to follow is to treat each bugfixing activity as a support epic into the Product Backlog. This epic needs then to be sliced down at task level (bug) and then managed into the limits of the Kanban(!).
But, after studying a piece of Kanban, the aspect of «... we’ve broken down in-process into two states: specify and execute. » gives him the aspect of introduction of specialization and it seems to “waterfallish” for him.
What is the best solution? How can he handle this? These are the questions that I’m trying to help him out without knowing the scope of all the project.
When nothing works “ask the team”!
Honestly, I cannot give a relevant advice with this piece of information. But I try to coach him out the bad path.
I didn’t know if the project is runned as an agile project: I just suppose that there is a bit of Scrum because of the utilization of specific vocabular and I understand that is a will to apply agile techniques (e.g. Kanban).
The main problem with methods is our addiction to it, to the detriment of the answers that they should deliver us. All the methods that Joe have marked are “virtually” good but really out of step with his needs: fixing the bugs.
I remember a discussion that I had with a Manufacturing Project Manager about the Toyota Production System (TPS) four years ago. He explaind me that every operator in the chain had a stop button. When an operator detected a defect (bug) he could stop the chain on its own. Clear the problem. Restart the production.
Is this running differently in agile projects? I think no. If a bug is detected, each team member has to have enough empowerment to stop the production of code until the bug is fixed.
... when nothing works ... ask the team! As the whole team is facing this problem, make a review and try to fix it, at last stop the Sprint and make bug-fixing Sprints.
It’s more complicated that it seems...
Joe cames back to clarifiy the scope of the project and let me know that it is more complicated that it seems (I love this sentence!).
The company has started a complete IT Department restructuration as a big bang for 5 years. This internal project consumed more than 100 million euros, have only 10% of the portfolio in production. The whole portfolio isn’t in production because 30% requirements are left, the delivered stuff is too unstable and needs urgent fixings. These are the product management issues.
The projects are managed in a “waterfallish” matter with a taste of Scrum: project teams can pull the specifications and are committed to the Release. (Ok! Hmmm). Joe has been promoted as Project Manager of a 30 headed team in charge with the development and 40% of the maintenance(!!!).
Regarding to my recommandations, Joe evaluates that he needs then to have 10 bug-fixing Sprints and during those Sprint no new or urgent business feature would be delivered. If he should ask his Product Owner, the bug corrections wouldn’t be set as high priorities. And at last, these Sprints might be critical for the team morale.
Learning to say no!
Indeed the scope is getting more complex but I keep my eyes open on the core: quality.
Let’s be logical. Making assumption that if you don’t fix the bugs then you scale up on unstable fundations. According to that, what will be the value of the 70% developped features? Just good for the trash? Or time and budget consumming maintenance projects handled by foreign development teams (e.g. outsourced!). I agree, I was a bit pushy...
Bug-fixing is not a left hand job. In agile, bug-fixing is a core point of the continuous team improvement process (like a Kaizen event in Lean). And if your intentions are to start Scrum, then you must know that in Scrum, the development team commits first to product quality.
In Scrum, like in any other Agile Methodology or Framework, the development team is self-organized.
The strength of self-managed teams is their adult behavior. Leaving spinning quality, thus releases, so risky estimates, etc ... reinforces the idea of an immature approach of Scrum and gives fodder to the "traditional tribes."
My advice on this is:
learn to say no!
Teach your Product Owner to accept only “done” items
If it’s impossible don’t make Scrum
It’s hard to say, but eXtreme Programing (XP) or Kanban fits better because it doesn’t impact the management.
A solution is emerging
Joe is back and balancing between increasing the product quality and respond to Product Owner’s requests. He thinks that at the moment he is unable to fix every bugs and a control chaos approach sounds for him more reasonable to increase its development visibility.
In other hands, the problem is not the existing bugs stockpile but more the incoming unknown and variable one. He confesses that very few unit tests have been made (!).
For the new features, he agrees that only “done” items would be accepted. And those might have a suite of automated unit tests and “OK” UX tests (if possible, automated too).
He understands now that without a minimum of bug’s control, every commitment stands as a problem.
A solution is emerging: Product Backlog cleaning with the help of XP and Kanban sounds promising. And when the development has reached an average level of quality then he wants to start Scrum. But, he agrees that it’s only possible with the agreement of the whole team.
- · No bug is a fairy tale. (the best rate I never saw was 95% in a XP Project)
- · Define a “Bug Ratio Transition Plan” with an acceptable Level of Done
- · According to the volume of bugs to fix, the team should reevaluate its level of done and its capacity to commit to the next Sprint
- · The Team focuses on bug fixing, during that time UX tests are managed by the Product Owner
- · When you have too much bugs to fix, automate all the tests
- · Trick for the Product Owner: if you have too much bugs in your Product Backlog your product is in trouble (really!) and you can start thinking to skip the last quarter of your Product Backlog because it will never been developed
Conclusion
eXtreme Programing (XP) gave the guidance in terms of quality coding and these practises are now widely adopted by agilists. In Scrum, these practises are know as Level of Done (LOD).
The LOD is the quality constraints that each team member needs to follow to address its commitment.
LOD is:
· the code adheres to standards
· the code is clean
· the code has been refactored
· the code has been unit tested
· the code has been built
· the code has a suite of unit tests applied to it
To reach this coding standard, the development environment must have:
· a source code library
· coding standards
· automated built facility
· unit tests harness
Scaling the agile evil!
Using agile techniques for your development is not a warranty to make good and stable software and it is not the Messia to solve all your problems. Contrariwise, using agile techniques reveals the defects and fosters people to learn through improvement.
When you are facing the same problem as Joe (it’s very common!), push the “stop” button, ask the team, fix the problem, deliver every month, improve, push the “stop” button, etc...
No comments:
Post a Comment