Latest Blogs by CharlesSee all blogs
Large Scale Agile and Scrum vs. Waterfall: Agile is 6X More Successful, 1/4 the Cost, and 10X Faster Payback!
A pair of recent findings from the Standish Group confirm the astonishing success and cost savings of Agile approaches over waterfall. In the "Chaos Report 2015", Standish found that large Agile projects are 6X more successful than waterfall projects. While Standish doesn't get specific on what is a "large" project, it's worth nothing that "Large" is the biggest size category for projects and their data encompasses over 10,000 software projects. In a new report called The Money Pit, The Standish Group studied two very similar large software projects, done at two very similarly sized, mature companies. One project was done with Agile, and one with Waterfall. The astounding results they found: The Agile project was 4X cheaper than the cost of the equivalent waterfall project, AND The Agile project was "delivered with high user satisfaction," while the waterfall project "had a watered-down critical function and the high-value feature was not part of the delivered application.", AND The Agile Project's payback was "At the end of two years the application costs were fully paid back and the users were highly proficient" while the waterfall organization estimated the system payback would "break even in 20 years" * Note that the activities depicted on the graph were done sequentially via waterfall, but iteratively via Agile. It should also be noted that a survey from Forrester Research showed that of all companies attempting Agile, some 90% are using Scrum. Just to re-iterate -- 6X more successful, cost payback 10X faster, and 4X cheaper. How is that for Better, Faster, Cheaper? At AgileSoftwareTraining.com, we provide coaching, consulting, and training solutions to help your company achieve the astounding success of Agile and Scrum approaches. Contact us today for a free consultation. So, if you're an organization that is doing waterfall or struggling with Agile, what are you waiting for? The research is overwhelmingly in favor of Agile and Scrum approaches. Get on the road to millions more in profit and cost savings. No seriously, what are you waiting for?
Aug 17, 2015
The Scrum Guide requires that the Product Owner ensure that "key stakeholders" attend the Scrum Sprint Review, but who are these "key stakeholders"? According to the Scrum Glossary, a stakeholder is "a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review." Typically, they fall into one of three broad categories: The Users - The human people who actually use(^1) the software product under development, to help them or the organization make more money or save money. This could include a human compliance officer within a company, who is responsible for making sure that the software systems comply with government or financial regulations. This could include the humans who support the operations or production support for the product. Upstream/Downstream systems could also be considered "users" so long as we don't forget the human end users of those systems. Don't forget the humans! Downstream reports are a good example of a downstream system" where you should definitely not forget the "human end user", but there are other examples. The External Customers (doesn't exist for internal products -- see below) - The people responsible for paying to use the software product. Only applies to externally sold or externally developed products By external here, we mean, outside the company doing the development. In a "software development for hire" arrangement(externally developed product), the client who engages the team would be the External Customer. Sometimes the External Customers and Users are the same people -- take TurboTax as an example, or a software product whose human users also make the decision to purchase said product. The Internal Customers - The people responsible for making the funding decisions for the software product development effort. This is usually someone in Product Management(usually for external products) or someone in management in the Line of Business(usually for internal products) that is supported by the software product. It could also be the CEO or CIO or similar roles at times There are probably exceptions to the above three broad categories. Also, don't assume that the Product Owner can only consider "key stakeholders" as sources for requirements or good ideas. The Product Owner can work with anyone any time (possibly during Product Backlog Refinement and other activities) who can supply good ideas to capture more value for the product. Our discussion of key stakeholders here is just to understand how the "stakeholder" role in the Scrum Guide can be interpreted. The key stakeholders are the people that receive a direct financial(^2) benefit(helps them or the organization make more money or save money) from using the software. One could also think of the management of the development organization as a stakeholder who should attend Sprint Reviews, certainly in replacement of any and all status reports and any and all other progress reporting for the Scrum Teams. If any Dev management asks for these things, the answer should almost always be something like "In Scrum, that information is communicated in Sprint Reviews, so let me get you on the invite list for that." For Scrum "key stakeholder" purposes though, I'm not sure I'd call Dev management "key stakeholders." or think of them as being "required" to be present(unless of course, they request status/progress reports). In some cases, you'll have so many "users" that it is not possible to have all of them in your Sprint Reviews. In those cases, try to get a representative sample of human users into your Sprint reviews(some companies pay for this kind of feedback from human users), and also utilize other feedback gathering mechanisms. Parting Words I'm sure that there are exceptions to the above three broad categories, so feel free to let me know if you can think of some noteworthy ones, or maybe see if you can effectively place them under one of the three broad categories above. Talk to the Product Owner and make sure that they are ensuring that key stakeholders are are attending your Sprint Reviews, as their input is absolutely vital to the success of the product. ---------- Notes: ^1 Rare exception -- note that sometimes a software development team acts as a "Production Support Engineer" user, but this should only apply to features actually in the product(support logging might be a good example) that help with production support. However, the modeling of a human user who is on the software development team should not become a guise for so-called "technical stories" or technical practices. That's not a real "user". ^2 Rare exception -- If the organization developing the software is a non profit, government entity, or charity, then instead of "financial benefit" or "money", we might say "the societal benefit" instead.
Jul 9, 2015
I have encountered many in the Agile community who love Scrum but seem to hate on the practice of Scrum of Scrums. Others describe their Scrum of Scrums as an overarching meeting of Scrum Masters, or as a meeting for a Product Owner team. In my experience, however, a Scrum of Scrums is a great way to scale the principle of the Daily Scrum, with the purpose of re-planning development work. If done properly, it's a great practice that implements Scrum’s core principle of bottom-up knowledge creation. Back to Basics Let's consider the Daily Scrum first. As the Scrum Guide™ describes, this is an inspect and adapt event for the *Development Team*. It is of the Development Team, held for the Development Team, and run by the Development Team. Only the Development Team members participate in the Daily Scrum. The Scrum Master helps out by teaching the Development Team to have a proper and effective Daily Scrum, reminding them of the purpose of the event, keeping it focused, and sticking to the time-box. The event itself is for the Development Team, and nobody else. The Daily Scrum’s purpose is for the Development Team to inspect and adapt their way towards meeting the Sprint Goal and delivering a potentially releasable increment that delivers value to stakeholders. Although the Scrum of Scrums is a way to scale the Daily Scrum, the event itself is not a mandatory part of Scrum. It is not defined in the Scrum Guide, and the Scrum Guide is the definition of Scrum -- therefore the Scrum of Scrums is not part of Scrum itself. It is considered “complementary", meaning the practice is not part of Scrum itself, but can be used in addition to Scrum. It is an extension of Scrum for a certain context, respecting Scrum’s underlying principles. Doing a Scrum of Scrums, if it makes sense for your context, is in line with the "ScrumAnd" line of thinking. Actually, you can do it even if it doesn't make sense, and Scrum will help shine transparency on whether the practice helps or not. Having said that, I recommend you try to honor Scrum principles when you implement complementary practices. Principle-Based Scaling If we consider that the "Scrum of Scrums" is a way to scale the Daily Scrum, why would the Scrum of Scrums be only Scrum Masters? Why wouldn't it be Development Team centric? I’ve heard of organizations practicing Scrum of Scrums as if it’s just a status meeting of all the Scrum Teams in an organization, regardless of what product they are on. This doesn’t strike me as a “principle-based” scaling of Scrum. It seems much more like a legacy/waterfall status rollup meeting in my mind. I subscribe to Ken Schwaber’s view that the Scrum of Scrums is for teams who are working together, on the same, integrated product. I believe and have experienced that a Development Team-focused approach honors the principles behind Scrum, honors the principles of the Daily Scrum practice at the team level, and results in more value being delivered sooner to customers. In my experience, an effective Scrum of Scrums, for and by the Development Teams, leads to a big boost in the Development Teams’ self-organization skills, impediments being removed quicker, higher quality products, and higher valued products delivered sooner. It would appear that the most credible sources in the industry agree that the Scrum of Scrums should be Development Team focused. Let’s start with Scrum’s co-creator, Ken Schwaber. In his book, The Enterprise and Scrum, Ken describes the Scrum of Scrums this way: “Scrum of Scrums are short, daily Scrum meetings at which an engineer from each team working on an integrated product gather to… keep track of progress between parts of the product so that they can more closely monitor any dependency or timing problems.” Mike Cohn, who has probably trained more Scrum teams than anyone on the planet besides the Scrum creators themselves, has this to say: "Each team would then also designate one person to attend a scrum of scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, or designer, for example—rather than a ScrumMaster or Product Owner." Craig Larman and Bos Vodde, who have extensive experience coaching Large Scale Scrum to 500 or more people working on the same product , describe the Scrum of Scrums as a Development Team "coordination technique" that people scaling Scrum should try. They suggest that you avoid turning the Scrum of Scrums into a status meeting or a Scrum Master coordination meeting: “Avoid...Scrum of Scrums being a status meeting to management... This is where the ScrumMasters meet each other and report their team’s progress to a program manager or a similar role. A Scrum of Scrums—like the Daily Scrum—is a synchronization meeting and not a management status-reporting meeting… Another smell: Scrum of Scrums is a meeting of ScrumMasters at which the ScrumMasters take responsibility for the cross-team coordination. In every case in which we saw this, the ScrumMaster mutated into a project manager within two iterations…" It’s worth noting that they do go on to suggest that the Scrum Masters meet regularly in a Community of Practice to learn and overcome obstacles – but not to coordinate or synchronize the teams like traditional project managers. Professional Scrum Trainer and Agile Coach Jesse Houwing confirms the experiences of Larman and Vodde in an email to me: “Using the Scrum of Scrums as an ‘aggregated status meeting’, whether you’re reporting status to management or just each other, is an ineffective practice. It shouldn’t be about reporting progress against a plan – those are wasteful legacy habits. The important topics for the Scrum of Scrums should be what the Development Teams are doing that might impact others, what they didn’t deliver on time or what they did deliver, but not as agreed previously. It should be about what they’re planning to do and what they need from the other teams. Let’s also not forget that the Scrum of Scrums is also about inspecting and adapting towards reaching the Sprint Goal – just like the Daily Scrum is for each individual Development Team.” In contrast, there is a scaling approach out there that suggests almost exactly the opposite of what these titans of Scrum suggest. According to their advice, they suggest that Scrum Masters be the attendees at the Scrum of Scrums. I wonder how many Sprints it will be before those Scrum Masters pull a “werewolf” and mutate into old school Project Managers? As a reminder, there is no Project Manager role in Scrum. Further, in my experience, Project Managers typically find it very hard to coordinate technical and other dependencies because they lack the depth of context required to do that effectively. Usually, in my experiences, they just become bottlenecks to progress. When I coach Scrum teams, I put a strong emphasis on honoring the foundational principles of Scrum when scaling. I encourage Scrum Masters, if they attend the Scrum of Scrums at all, to stand "outside the circle" of Development Team members, and to avoid eye contact with Development Team members as they are collaborating. Because I believe in principle based scaling, it’s probably no surprise to you that I coach the same technique for Scrum Masters at the individual Development Teams’ Daily Scrums too. I want the Development Team members to be empowered to truly self-organize in their coordination and collaboration efforts. Yes, of course I coach the Scrum Masters to be servant-leaders and facilitate as wanted or needed -- but I also encourage them to fade to the background as soon as the Development Team can have an effective Scrum of Scrums on their own. In Conclusion A Scrum of Scrums is probably not the only “scaled” Scrum event or technique that you will need on a multi-team, one-product effort. Each of the other optional/complementary “scaled” techniques is worthy of a blog post of its own. On the other hand, maybe not every scaled Scrum implementation needs a Scrum of Scrums event. Your mileage will vary and you will have to inspect and adapt as always. Ignore the haters and the people who like to treat the Scrum of Scrums as a punching bag. Don’t be afraid to try for an effective Scrum of Scrums. My advice is to assess your own context, to look for practices that you think might work to scale up, but to do so by putting principles first and your best foot forward. I wish you well and… Scrum On!
Jan 29, 2014
Professional Scrum Master I
Professional Scrum Master II
Professional Scrum Master III
Professional Scrum Product Owner I
Professional Scrum Product Owner II
Professional Scrum Product Owner III
Professional Scrum Developer I
Scaled Professional Scrum
Professional Agile Leadership I