A recent discussion on the Certified Scrum Trainers list regarding Sprint 0 and what was a product prompted me to write a long reply I have posted here. Mirage Scrum is the kind of Scrum that some people practice, where what is being developed looks like something it is not.
This is a true story describing a project that used what I am calling Mirage Scrum. The Scrummaster on this project was a colleague that I advised.
The VP in charge of a large program to integrate a bank’s online products came under the spell of a Boston Consulting MBA consultant with no dev experience and a user experience fixation. Based on the consultant’s advice, a project was setup to create the “vision” of this project, in this case the User Interface for the integrated product portal. The project team was to design the interface using a tool called iRise, that creates clickable UIs, along with typical graphic design tools.
For 3 months this project team worked in creating this User Interface (UI) using Scrum. They had a consultant Scrummaster, a scrumboard, demos, and 2 week sprints. They would demonstrate progress on the UI in the iRise tool. After 3 months they had finished the UI design in the tool, and shown it to all the executives in the bank, who approved, though many wanted to adjust colors, move things around on the screen etc. Everyone has an opinion in UI.
This UI concept was then given to the development organization. Then the fun began.
The iRise tool claimed to generate all the code needed. Well, what it generated was not usable for much of the site, so development decided on PHP. The UI design made many assumptions about the backend that were wrong, so many UI elements had to be reworked. The UI design did not have the correct security interface. Etc.
The executives who saw the completed UI in iRise asked why, 4 months after the final interface demo, was the portal not done?? Development needed to go faster. Marketing projects had been started to market the online portal based in part on seeing the completed UI in iRise. Investments were being made with ad agencies, printers, TV, media and online.
Yet massive data-warehouses had to be developed to integrate data and abstract the portal away from the many disparate systems. Acquisitions that had completely different systems and environments had to be integrated. A very large amount of development remained. This development needed to be rationalized against the UI concept, and tradeoffs, changes, and revisions made. It took a year to get the first version of the portal launched, and multiple releases to complete all of the features needed by each product.
So did the UI project add value? Yes there was value, the same value as there is in a requirements document in a waterfall project. Except that the UI project, with its demos of clickable UIs, created an impression of “done”. Based on what Managers saw in the demos, decisions were made and investments taken. Stakeholders believed the Mirage the UI team had created using Scrum practices. You can imagine the conversations between IT and marketing for the following 12 months. Many expectations to manage, IT seen as slow and always making excuses, money lost on purchased advertising space option contracts, and ad agencies doing multiple revisions to marketing material based on the changes in the system under development.
As an Agile Coach in the organization I consulted the SM and tried to persuade the consultant early in the program to find another way that would create real software. Instead of a UI based on assumptions. The consultant had lots of political support for his approach. He said the Company had lots of “consumer anthropology” that needed to be done that could not wait for real software. Since arrowheads and pottery shards were in short supply, I think he meant showing the UI to users, perhaps doing some usabilty tests? I am still not quite sure.
Can you create a vision with using scrum practices? Absolutely. Are you implementing waterfall in 2 week sprints? Absolutely.
Mirage Scrum. Using Scrum practices to deliver artifacts that create the mirage of completed software.
Agile 2010 is only a few weeks away, and it should be a very good conference this year. After the being the Producer of last year’s main stage, I am looking forward to being more involved with doing presentations and participating as both a speaker and a listener. I also really enjoy this conference for the all the great people I spend time with at the talks and in the halls. I hope we will see you in Orlando!
On Tuesday August 10 I will co-presenting with Jurgen deSmet on the Large Scale and Distributed Agile Stage.
Cooking the Product Stew
What is a stew? A stew is made from various ingredients you have around, left overs, new ingredients that go together well, and others that are filling but need lots of sauce. The enterprise software market is made up of products that are a stew of software on many legacy platforms that have evolved over a long period by many hands. Taking an enterprise software product to Agile methods is a challenge. In a uniquely European context, this presentation will draw from the ongoing agile adoption in a multi-location multi-team enterprise product with 460 staff in 4 countries and 5 locations.
On Wednesday August 11 I will be co-presenting with Yves Hanoulle on the Agile Coaching Stage.
What I learned from burning my parents’ house down!
In July 1991 Yves’ parents went on holiday leaving him (19 years old) to guard their house. On August 1 at 19 hour 36 minutes Yves parent’s house burns down. It was Yves fault. And yet it was the best thing that happened to him till 2002. If you want to know why, come to our session. This interactive talk will show you why a crisis is a good thing. We make the link to agile transitions and how coaches can use a crisis. Why do people change? Do we consider their interests when making a change? This talk is based in part on the book “A Sense of Urgency” by change management expert John Kotter.
In September this year I gave a keynote presentation with Jurgen De Smet at the first Agile Eastern Europe conference. Our presentation was about a company that over 12 years and many acquisitions has grown a software development environment that is very difficult to manage. With humour and the cooking show format we take a look at the dysfunction and complexity in this environment, how it arose, and discuss approaches we would take to improve the situation. Enjoy!
Jim Womack recently published a brilliant eletter on lean.org. In the letter Jim discusses the many challenges GM faces coming out of bankruptcy, and the challenges Toyota faces from its rapid expansion. The eletter is great but there are some choice quotes I would like to publish here:
On the message from GM’s Bankruptcy:
“Yesterday also marked an end of the lean narrative that has been unfolding for thirty years, ever since GM first began to decline in the recession of 1979. David (in fact a team of Davids) finally felled Goliath just as Goliath was finally paying attention to the lean message.”
On GM’s management:
“It is easy to blame GM’s recent management for its troubles. But the senior GM managers I have known – almost all of whom had strong finance backgrounds –were remarkably competent at running the company in the financially oriented, manage-by-results way that had produced success for generations. So the problem is not the individual competence of managers but GM’s irrelevant conception of what management needs to do.”
On what is next for Lean:
“We in the Lean Community find ourselves in the odd position of winning a battle of ideas without actually getting most believers to fully practice their new convictions. And we have as our ideal organization a company that is experiencing significant management and revenue challenges despite “winning” the great contest between modern management and lean management.
… Lean ideas are spreading rapidly to new fields, from the beleaguered financial industry to healthcare to government services. Yet we have not fully defined what lean means in these areas, much less how to implement and sustain it. So the dramatic events of recent weeks are not a time for self-congratulation. Instead, they are a time for modesty and self-reflection – hansei, if you will – as we all struggle with the economic crisis while trying to re-define our own purpose as a Lean Community for the new era ahead.”
Martin Fowler recently posted the blog entry “Flaccid Scrum”. Martin makes some good points on Scrum and its adoption without the corresponding agile engineering practices. The observations from his colleagues are common, as teams that are new to Scrum and Agile techniques are learning a new way of working. Scrum implementations lend themselves to adoption of Agile engineering practices. The messy code problem is not a result of Scrum, it is Scrum that has brought visibility to low quality code. Having to put code into production early and often forces teams to recognize defects that otherwise would remain hidden for months in a waterfall process.
Semantic diffusion – Martin’s term for the observation that definitions become diffused over time is an interesting idea. In doing Agile adoption at a major Financial organization we called this “death by a thousand copies.” Someone would have a practices based definition of what Scrum was and then share it with other people, with no references back to the underlying principles. They would modify practices to suit their environment, and those practices would become the defacto “Scrum” for that group. Why does does this occur? We found it was because people did not understand the basic fundamental principles of “why” certain practices are put in place. In the market we see many “ScrumBut” implementations of Scrum, where the basic principles and practices of Scrum are are known and understood but not followed. This phenomena is not just a Scrum problem, Object Oriented development and adoption of Lean principles in manufacturing (outside of Toyota) have also been poorly implemented at various organizations. Each implementation however poorly done, gave some benefit to the organization, often a short term benefit. For example car manufacturers like GM learned how to lower inventory and remove waste from their manufacturing plants.
The time tested way to deal with semantic diffusion, death by a thousand copies, and poor quality code, is to implement two foundational values: respect for people and continuous improvement. Respect for people in Scrum is articulated in ideas such as self organizing teams, pull, and commitment based planning. In Lean it is exemplified in the authority that any worker can and should “stop the line” to address defects and implement solutions that eliminate the root cause of the defect. There are many other examples of respect for people. At Toyota employees are expected to continually improve the process, and if it eliminates the job they were doing the company will find another place they can continue to make improvements. In August 2008 Toyota closed two truck plants in the US but did not do any layoffs, instead putting 4500 employees into a massive training program. This security empowers people to implement improvements knowing they do not need to “protect” their current job on the assembly line. Compare this to the Financial organization that employs talented software engineers to implement repetitive tedious manual production release processes instead of empowering these people to build standardized automated processes. Those same engineers have no interest nor are they asked to implement these automated systems because it would threaten the existence of their jobs and their manager’s jobs.
Continuous improvement, also called Kaizen by the Japanese, is the daily work of finding and implementing improvements to the process. In software the process is how to go from an idea to working testing software in production. Those improvements should result in ever faster translation of ideas into software with less effort and less cost. In North America we are obsessed with Goals and Objectives. However what happens if our goal is to never be satisfied with: the current process of delivering value, the quality, and the cost? How do you achieve perfection in the delivery of software for your customers? How do you do that in the shortest cycle possible?
Scrum does not tell software developers to use test driven development, continuous integration, pairing, or automated testing. Scrum was created that way on purpose. Once you start using Scrum, implementing these practices should be part of the continuous improvement cycle. Learn Scrum, learn XP, learn Lean, learn Theory of constraints, and most importantly, learn what your customers need and strive to fill those needs using these great ideas.
A basic pass / fail test was developed at Nokia to understand if the many teams were implementing Scrum correctly. You can take this test by clicking on the link below.
I will aggregate the results and email them to you if you are interested. I will present the results back to the Agile/Scrum community for discussion once we have 1000 responses.
As of January 26, 2009 we have 208 responses.
Please forward this email to other teams so we can get as many responses as possible.
As Agile becomes more mainstream and the knowledge base grows, staying in touch and contributing to the community grows in importance. The conference of the year in the Agile community is Agile 2009. Agile 2009 has the largest attendance, the most participation, and the largest number of sessions. I am continuing my involvement and contribution, this year I am producing the Main Stage events with the help of Bill Wake. I encourage you to take a look at the Agile 2009 Open Submission system http://agile2009.agilealliance.org/ and see the proposed presentations. Agile 2009 has an open review process where anyone who registers can comment on the proposals and provide feedback to the submitters. Have some new ideas that you’d like to contribute? Please do add a submission. If you have a specific experience with Agile methods that you think is a great war story, then an experience report would be a great option.
While Agile 2009 is about Agile methods, culture, techniques and principles, Lean and the Toyota Production System continues to gain influence in the community. The maturity of ideas and the experience of thought leaders implementing Agile has lead to Lean. Lean improvement tools and ideas beyond software development to the whole process, from customer request to request fulfilled. This expanded scope of process improvement is new to the software development world but it is a healthy and logical place for continuing expansion in the process of improving delivery of software systems.
A benefit to successful presenters is free conference registration, and for longer talks hotel accommodation is also included. See the web site for the details.
I hope you will check out the Agile 2009 site and get your submissions in! The deadline for submissions is February 13th.
I was recently in Ghent, Belgium to give public training sessions and a talk at Agile in Belgium. My colleague and friend Jurgen de Smet and I conducted a Certified Scrum Master class, and I launched a new one day intensive course on User Stories, Paper Prototyping, Agile Estimation and Planning. Jurgen did a very nice write up on the class on his blog User stories, paper prototyping, estimation & planning where he outlines the course and his impressions. However he didn’t mention the business case. The business case is the development of a Belgian Beer portal to sell the many hundreds of varieties of Belgian Beer! For those who don’t know lager from ales, the Belgians are world beaters at creating and selling great beer. The largest beer companies in the world are based on Belgium. In fact Budweiser’s parent company was recently bought by the Belgian-Brazilian company InBev, the world’s largest brewer. What has this to do with Agile, Usability and Scrum? Well if you are going to fulfill the business case for supplying large markets with the many niche beers of Belgium, why not use Scrum? It is the fastest way to go from customer need: I am thirsty for a Trappist monk brewed beer, to need fulfilled. Ahhh! that is a fine ale. Of course if you are in Belgium, then a trip to the store is probably a little faster and cheaper. The business case gives participants a specific market and product with its technical and non-technical challenges. The Product Owners need to account not only for the features and the web site but what other things need to be done to get the web site off the ground. The exercise is to recognize the resources are scarce for all the work required, and how do the decisions made in one area, for example fulfillment, impact the site features.
Working on the paper prototype. Here the discussion is about what really is the minimum UI and functionality the portal can enter the market with. Like any web site, there is always more to do… but what can you afford to prove feasibility of the business case? Belgian beer can aid with these agile discussions.
If you are interested in having the User Stories, Paper Prototyping, Agile Estimation and Planning course taught publicly in your area or for your company, please contact me at rdymond atdeletethis innovel.net. I have other business cases that we can use for the same exercises.
Kiev Ukraine: After 5 days in Kiev, I learned much about the state of Agile in Ukraine, and the state of business in Ukraine’s capital. My first visit to the Ukraine held many surprises. The downtown area of the capital was interesting, attractive, an similar to other European cities. The architecture combined Soviet style massive design, buildings with intricate architecture similar to classic European buildings, and more modern apartments and offices. Beyond the buildings to the street, I expected to see clear signs of a depressed economic region, like closed shops, bad roads, and inexpensive transportation. However this is the capital of a 45 million strong nation, and I was surprised. Construction cranes were everywhere as new offices and business centers were under development. More surprisingly, it seems the Lada has been replaced by the Porsche Cayenne, Bentley, and High end Mercedes as the cars of choice in Kiev. A Bugatti Veyron? Yes. I saw a higher concentration of high end cars on the bumpy streets in Kiev then I have seen in London, Brussels, or Paris. I quizzed my hosts about this, and heard a combination of embarrassment and frustration. It seems for politicians and bureaucrats of the Orange revolution, Kiev is open for business that will fund their new, rich lifestyle. This was set against the backdrop of the crisis in the world financial markets and massive spending of taxpayer’s money for disastrous portfolios of high risk mortgages and credit insurance swaps. As someone who helps teams and businesses better compete legitimately, seeing the corruption implied was disheartening.
Meeting the people in the Agile community in Kiev and at the Certified Scrum Master class reminds me of why this is a great profession. The Certified Scrum Master class was a mix of software developers, managers, QA, business analysts and even a couple account managers. While half of the students had been doing Scrum, we also had people who were completely new to Scrum and Agile. We generally have smart people in our profession, and this class was no exception. While the class was in English, the exercises were in Russian. My Certified Scrum Master class covers a ton of material on Scrum, Agile principles, roles of Scrum, and how to establish Scrum with a team. The class asked good questions, and were sometimes surprised by the results of the many exercises we did. With this class I dropped the “59 minute Scrum” in favor of the “Save Earth” and “Ball Points” exercises from CST Boris Gloger. The exercises are great ways to show how we can fail or succeed based on our own personal actions, and they also put students in a different frame of mind, loosening their preconceptions from past experiences.
My main challenge with English as a second language classes is usually pacing. I choose words more carefully and I go slower to ensure understanding. With a packed agenda this means something needs to drop, but, like an over eager development team, I sometimes over commit, trying to squeeze in too much material. The rise in knowledge of the students and the deeper experience of the trainers may lead to a 3 day course. Some trainers such as Mike Cohn and Mishkin Berteig have already adopted a longer format, with Mike offering 2 days of training on requirements and planning around the 2 day CSM class.
The Agile Ukraine gathering 6 on Saturday 10/12/08 was a great opportunity to meet more of the Agile community, as over 150 people packed a large conference room for the day’s events. There were numerous talks from Ukraine’s Agile advocates and thought leaders. Alexey Krivitski is the organizer, and single handedly put together this event for the community. I encourage more of Ukraine’s Agilists to lend a hand and take a leading role with Alexey to create sustainable group of organizers of Kiev’s Agile community. Topics at Agile Ukraine gathering included Introduction to Agile, How we do Scrum, Agile Metrics, mixing Agile and RUP, and Agile and business. I had the opportunity to provide the Keynote presentation on Lean, value stream mapping, and how to apply lean principles to Scrum and Agile projects.
I covered the history of the Toyota Production System, and how speed delivers a competitive advantage to businesses. Most of the IT and software teams in the Ukraine are engaged in offshore projects. Lean can provide a great way to highlight what slows their offshore teams down, and gives them a way to articulate this to both management and clients. The culture of eastern Europeans has an advantage over Indian teams when using Agile methods. Transparency means teams need to have courage and be honest with their customers. This means saying no, managing expectations, and building trust. Teams that always say yes, don’t manage customer expectations, and then hide when it becomes clear there is no way the team will meet the commitment is common in offshore teams. The culture of eastern Europe is not socially hierarchical and there is a tolerance for open discussion and debate within groups. This means teams in eastern Europe are biased to Agile methods when compared to teams from hierarchical cultures like India’s caste system. I don’t think Ukraine outsourcing poses any threat to the Indian outsourcing industry, however Agile is a growing market where Ukraine outsourcing can have a competitive advantage, provided that they can demonstrate and market this advantage. I will update later with photos from the events.
– Robin Dymond.
I often hear: “How I can use Agile on support teams who do defects and small enhancements on multiple platforms?” Support, “business and usual,” defects, and enhancements are ideal for an Agile team. Think about it for a minute: the changes are usually small and independent, they are doable in a short time, and can often be deployed without major architectural or data related changes. This article describes how Scrum was modified to improve a support team’s process.
In the fall of 2005, a production support team of developers, testers, and analysts was setup to support 5 different production systems. The team was responsible for completing customer support requests for defect fixes and small enhancements. Major enhancements were handled by the platform teams. There were 5 different customers that made requests for each system. The team was setup to use Scrum, with Amy Ripley, CSM as Agile Coach and a single Product Owner. The Product Owner worked with the customers to define a single product backlog with priorities for all requests across the 5 systems. While each customer had different needs, many of the systems had interactions, so priorities were easier to determine than if all were disparate systems.
The team was co-located in an Agile team room and started out using standard Scrum with a 3 week iteration length. As the team and the Coach worked together, they realized that Scrum did not account for some of the unique properties of an enhancement and defect support team such as:
Customers want quick turn around on fixing defects found in production
Defect and enhancement implementation is small piece work compared to building new application features
Requests for changes are independent of each other
Managing 5 customer’s expectations lead to pressure for more frequent updates to production. The Coach and the team saw this as a valid concern, and decided to make changes to their Scrum process that would better suit the small piece work and customer needs for faster turn around. The changes included:
Weekly releases to production. Given the production support nature of the team they changed their release pattern from once per 3 week iteration to weekly releases.
Allowing work to cross iteration boundaries. Some requests would be started later in the iteration but could not be completed by the iteration’s end. Given the weekly releases, this was acceptable, since the customer would not have to wait for a whole iteration to see the item in production.
The regular story board was not providing enough clarity as to what was in progress and its state. A more structured Kanban style board would allow the team and stakeholders to more accurately track progress of work items. A Story board was implemented to show the status of a User Story that was in progress. The story would move with its task cards through analysis, dev, test, and release columns on the board. Each the 5 systems had rows for their stories.
A team agreement was made to take each work item from beginning to completion before starting a new work item. As could be expected in a large organization, issues frequently came up that would stop progress a work item. When progress was stopped by obstacles outside of the team’s control, then a team member could start on a new work item. These obstacles were escalated to the Coach, the Product Owner and management for resolution.
This kanban style User Story board really helped the Scrum team, Product Owner and stakeholders understand the state of work at any time. The kanban style User Story board also helped reduce work in progress, since once a story was started, team members would not start on another story until it was completed.
The team continued to use the Scrum practices of self organization, the 4 meetings and a 3 week iteration length. The team and stakeholders valued the planning, it helped set expectations for everyone as to what could be completed in the near term. The demo meeting allowed the 5 Customers gain visibility into all the work done by the team. This “see the whole” is a key principle in Lean and with this team it provided a key benefit to maintaining stakeholder equilibrium, as all of these systems served the same department and overall business function. The Scrum principle of self organizing teams was also maintained, as they achieve higher performance and have higher morale than directed teams. Self organization also frees leadership to innovate and create more effective work environments.
Congratulations to Agile Coach Amy Ripley and team for inventing this Kanban style board and process for their Scrum.
“Two strong personalities and too much debate. Need is the mother of invention”
– James Grenning on inventing Planning Poker
This 2 day course covers how to use Scrum to manage your Agile projects. Students gain an understanding of Agile principles, Scrum practices, and how to manage the Scrum process. Recommended for project managers, technical managers, and technical leads.
Current classes are listed on the Scrum Training site.
This 2 day immersive training is great for teams who are looking to adopt Agile for their project. Team members come away with a solid understanding of how to work day to day on an Agile project, how it changes their role and what they should expect. It covers Lean, Agile, and Scrum, with a focus on the Scrum project framework.
