Scrum 2013: (R)evolution needed?
We’re ending 2012, all of us worked on a lot of challenging projects! So cool! And the Future looks bright with more than ever promising trends (mobiles, tablets, HTML5, Cloud …). It did not start this year but technology invited itself in every aspects of our day to day: everything goes fast, productivity tools for our professional and personal lives bloom every hour… Software publishers are happy nowadays. Plenty of start-ups emerge and the software development industry is doing well: Cloud-based solutions, collaborative tools allow people to start businesses and develop solutions with limited initial investments. In this area, productivity is progressing.
When it comes to process and methodology, Scrum is the leading framework. It is used by thousands of companies around the world. Jeff Sutherland created Scrum in 1993 and helped write the Agile Manifesto: it undeniably changed the way IT projects can be conducted. We could list hundreds of good reasons to go down that road. But wait… Many agile team members struggle understanding the basics of the method. There are many pitfalls of Scrum to the newbies and Scrum definitely has weaknesses. Some are discussed within the community, some are just omitted: in all cases I believe things should evolve in 2013, enhancements are needed.
I claim here that Scrum is very suitable for software publishers having one or two major products with stable and small/medium size teams. It’s a totally different story otherwise.
15 Scrum 2013 “good resolutions”:
- Scrum is generally brought by IT: this is a mistake. Sponsorships should come from the entire corporation, including business and top management. Expectations should be identified, benefits and problems listed, you don’t want to implement Scrum just because everybody else does.
- There are very few good product owners (PO): Backbone of the process, this role needs education and implies multiple competencies. The PO will be discussing with business and technical teams and it requires multi-disciplinary skills. Good developers are, of course, a unique asset but this academical discipline of coding exists since years: you will find them. This is not yet the case for Product Owners.
- Being “value-driven” is tough: one major concept of Scrum is first to spend time on what brings value to the software or the company: you want to avoid the scope creep effect or spending time in developing functionalities that won’t be used at the end. Value-driven seems like a very legitimate approach but is still far from being systematic. People continue to consider the effort as part of the equation: they tend to put the maximum of features in a release independently of the value of the feature.
- Scrum is a business: many organisms provide services around this. You become scrum master after a two-day training… Reality is that you know nothing after two days: clarity should be brought to this area. Too many consulting firms and fortune tellers try to take advantage of Scrum promises.
- Estimating processes: the process of estimating user stories is far from being mastered. Points, complexity, effort? Accurate estimating is at the foundation of correct planning management. It is very frequently empirical and not bullet-proof. Poker planning does bring a first level of answer but is too light in many aspects.
- Distributed teams: handling geographically spread teams with different time zones, cultures, companies, etc. is a pain! This can happen with both internal and external teams, for instance when outsourcing some pieces of development. Scrum requires proximity and a lot of face-to-face interactions. No true satisfactory answer exists so far.
- Teams not fully dedicated: you cannot be agile at 75% of your time. In corporations, many resources, even developers, can be dedicated to different tasks (e.g. support) and these cases are hard to conciliate. Needless to say the situation is even worse if you’re planning to have only part of your teams agile (e.g. one agile team of 7 members among 30 developers following other frameworks)
- Unstable teams: turnover is always difficult to handle but key concepts such as velocity are heavily impacted. It’s hard to incorporate new developers in agile teams. Learning curve is important and you don’t easily change members of a team.
- HR aspects: Change management is critical. Bringing Scrum into an existing organization is an extremely impacting and difficult activity. Career paths of developers, business analysts and project managers change and should be clarified. HR should be presented the method and accompany this evolution.
- Multiple products: development teams can develop and maintain several products. I mean totally different and independent products. It leads to many problems: several POs (cross products priorization is a nightmare), staffing issues (resources are not interchangeable, not everybody knows every product), technical tasks (building, packaging, etc.) become tedious. PMO, Super Product Owners can help, but hanling 30+ applications portfolio while remaining 100% Scrum compliant proves to be an illusion.
- The big picture is missing: Scrum (through Agile) promotes collaboration over contract negotiation. You basically commit on means, not on results. This is a pragmatic approach based on the trust that the technical team will put all appropriate means to reach the best product possible (and the one truly meeting the needs). A steering committee, executive sponsors however need additional elements to validate budgets: the decision making process is drastically impacted and you’ll have to fight a lot with this. You basically agree on a capacity and will be delivering what you can with that, the question coming from the top management is usually asked totally differently: “what do I need to develop this?”
- Feature driven: what’s working well for regular user stories (i.e. developing a specific feature) is more complex/less obvious for transversal tasks (deployment, bugs fixing, architecture, etc.) where the role of the PO could become blurry. Should all activities be translated to user stories? How to integrate these items in your product backlog (a feature vs. a technical improvement)? You end up many times tweaking the standard process to handle these cases.
- User stories and product documentation: consolidating user stories and maintaining central product documentation is difficult. The role of business analysts/technical writer in maintaining functional specifications should be handled carefully. The way epics and user stories are written is different from a proper user guide.
- Technical promises: continuous integration and code refactoring take time. This is a long-term winning strategy but not everybody can afford it. This task is complex, does not bring immediate value and requires highly technical profiles to be managed properly.
- Myths: Scrum brings false ideas or encompasses too many concepts (e.g. being iterative does not mean you’re agile). Playing with post-its just distracts people from asking good questions… I recommend this great post from implementingscrum.com
Time has come for Scrum to make its (r)evolution.
There are no comments yet, add one below.