This is the story of how the Scrum of Scrums has evolved for a large program I’m helping out with at one of our clients.
This is the story of how the Scrum of Scrums has evolved for a large program I’m helping out with at one of our clients.
Two nights ago I had a great discussion with my son, Justice Berteig, about how we have been managing to do house cleaning every week. We have been using a very basic Kanban system. I have created about 100 stickies each of which has a basic cleaning task such as “tidy the kitchen counters” or “vacuum the office floor” or “clean the powder room toilet”. If we do all of the tasks, it represents a fairly complete cleaning of the whole house. Every Saturday morning, all six of us (myself, my wife and our four kids) choose one task at a time and put the sticky for that task in the “In Progress” column. When we finish a task, we move it to the “Done” column. When all the tasks are done, we all are finished. We reuse the stickies each week. Sometimes if we want to do a quick clean, we won’t put out all of the stickies.
It works well in one specific way: everything gets done!
But Justice was complaining about the system because he works a lot harder and one of my younger kids has admitted to doing less than she could… because she can get away with it with this system.
Last week we tried a modified system where each person has a task allocation. For example, Justice had an allocation of 25 tasks. Our younger daughter had an allocation of just 5 tasks. We then took turns to choose one task at a time (although there were a lot of exceptions to this) until all the tasks are pre-allocated (similar to how teams used to do Sprint Planning). But, although some people finished all their tasks, not everyone did and so there were a number of things left over that never got finished.
In other words, we stopped using a Kanban system, and we stopped reaching the overall goal of a clean house.
So Justice and I had a long conversation about this problem. In the interests of continuous improvement and experimentation, I didn’t just force the issue back to the old Kanban system. Instead we decided to try the following changes:
I’m going to add one more thing which is to do a specific retrospective on how it worked to see if we can come up with further improvements. I have to admit that I hope we go back to the Kanban approach!!!
Check out our new Kanban training offering: Kanban: Gentle Change currently available for public enrolment in the Toronto area and for in-house delivery wherever you might be!
I wrote this article for our Real Agility Newsletter, but I wanted to share it here too, just in case some of you don’t get it. I think this is important to share because it gets to some of the deep values of Agile and good teamwork.
– – – – – – – –
Our business has been through crisis before. In the second half of 2005, my own financial mis-management led to near-bankruptcy for the business and for myself personally. My dear long-suffering wife and business partner, Melanie, kept things under control as we recovered. In late 2009 the Great Recession hit us hard and we had to cut our staff back to just Paul and myself by laying off three talented friends and cutting work to a loyal subcontractor. That was incredibly painful for everyone involved. A similar crisis occurred again in late 2011, although it wasn’t as severe. In September last year, our projections were showing a looming crisis… but we narrowly averted any layoffs when a smaller consulting deal closed and one person was let go for unrelated reasons. We still needed more work, and in late fall we were expecting to close three important deals.
In January we knew we were in trouble. Business was not booming. In fact, those three important deals had fallen through with nothing obvious on the horizon to replace them. Our office management was in a shambles with two recent changes in staff and very little continuity. Our accounts receivable had several items that were waaaay overdue. We were starting to dig deep into our operating credit with no obvious way to climb back out. The partners, Paul, Travis, Melanie and I started to talk about serious stuff: deep layoffs. We were worried we may even have to cut all the way back to just me doing work (mostly CSM classes) – a staff level we haven’t seen since 2007!
Two weeks ago, the four partners had an emergency weekend meeting after our early February attempts to build sufficient immediate cash flow failed. We consulted for over four hours around a single question: what should we do? Our projections were showing us running out of credit in just four weeks, our business development pipeline was almost empty and the few things in it were clearly long-shot deals, at least in the timeframe we needed. It seemed almost impossible to avoid deep layoffs. Our love for each other seemed almost irrelevant to the crisis, despite the depth of our feeling. The consultation was difficult and filled with despair.
My memory for exact words is poor. I remember concepts, relationships and feelings. During that weekend consultation, one thing really stood out: we started to talk about commitment. We talked about what it would mean to be committed to each other and to the business vision of transforming people, process and culture. Most powerfully, we talked about the commitment of our newest employee, Nima, who seemed determined to go to the ends of the earth, to the very last moment to help us all succeed. As we talked about commitment, we came to our most powerful decision: sink or swim, we are all in this together to the end.
After that critical point in our discussion, we set some goals, determined some important activities, and decided to go literally day-to-day in deciding if it was time to wrap up the business. And, strangely enough (I say ironically), we decided we needed to shorten our planning cycle from a month to two weeks, increase the discipline of our team’s interactions to bi-daily check-ins, create a detailed set of dynamic plans for the two weeks, and have a review meeting at the end of the two weeks. Sounds a bit like an Agile team, doesn’t it?
What happened? Well, we’re still around. We’ve closed enough business that our projections are now showing us staying in a steady state financially for the next three months. That’s a dramatic turnaround from just two weeks prior. We aren’t going to run out of credit. In fact, we now have enough prospects that we expect to be extremely busy in just a couple more weeks. Our end-of-cycle review, which happened on Friday, was still difficult. There is still great uncertainty about many things. But the one thing that is crystal clear, strong as steel, and deep as the deepest ocean is our commitment to each other to succeed together. We are a true team.
– – – – – – – –
If you have similar stories to tell, I would love to hear them!
Recently, I was able to witness a remarkable event in a company that is relatively new to Agile. They have several teams at about Sprint 12, with several new teams just starting up. Many of their processes are waterfall based.
A failed waterfall project was moved to an existing Agile Team.
In the second Sprint, the Team (feeling trust in the organization and the process), came to the Scrum Master and said, “We’d like you to talk to management. We are not sure this project should be using the platform we develop on. We think another team’s platform may be more appropriate”.
The company had spent time developing a “specification document” for this “project” before Agile was introduced. There were detailed specifications as to how the product was to be created and which platform to use. NONE of this was done with the benefit of asking those that would actually be doing the work.
The project was initiated before learning about applying Agile. One developer was tasked with following the specification. After 2-3 months of frustration, the developer left. This left the company in a bad position. Not only was the project incomplete, but there was also no knowledge transfer. The project was basically stopped.
As Agile was now the new target way of doing things, the project (and new developer hired through the previous process) were added to an existing SCRUM team. The team is using one week Sprints.
After only two Sprints (two weeks), the team had recognized the futility of the approach that was “specified” and took this to management.
Traditionally, large organizations staff for projects. In an environment such as this, how could team members be expected to be truthful and honest about the state of affairs? It would mean the end of their jobs or contracts.
The key here is to allow teams to stick together. Not only will you avoid losing all the efficiency the team has built up, but you will also allow them to be truthful about their situation.
If you are a manager reading this, ask yourself. “Do I want to know that things will go wrong at the beginning of the project or wait until 5 months have gone by to be told, ‘We knew it would never work””. Or even worse… “We knew the product owner was asking for ridiculous features that had no Return on Investment for the company, but hey, you hired us for this contract. We just follow instructions”.
As it turned out, the project did continue with the current team, but with some changes to the specification. The parts of the system that were going to be problems in 5 months were re-evaluated and were removed as they really did not have any real value to the company. It was then decided to stick with the same platform.
Discussions did occur regarding moving to the alternate platform, but were deemed unnecessary after open discussion between the teams and the managers involved. Realistic expectations were set based on value to the company.
Sometimes features are absolutely mandatory for the product. This cannot and should not be taken away from the process. What we gain here is that we are able to have a discussion about necessity. In the end, the business has to decide what is valuable, not the development team.
In a case like this, ask yourself, “If my team is very against this, maybe I should at least think about it”.
The company is working in a very short iterative environment, they quickly recognized a flaw in the system design and dealt with it after only 2 weeks into a several month project.
Working incrementally allows the company to “Inspect and Adapt” on a regular basis. This has to include the question, “Does this still make sense?”. If you need to go backwards, let it be to reverse one or two Sprints of work, not months, or even years.
Fortunately, for the company, the product will come out on time, with appropriate technology based on Return on Investment, and likely with significant cost savings over the initial design. This will also allow the team to get started on other high value projects. Talk about win-win.
This project could have gone to another team. It would not have been negative for the first team. The next project would have just come down the pipe for them.
The early signs helped adjust the “expectations” and everyone is moving forward with a clear understanding that they are on a more appropriate path going forward.
For those of you out there trying to convince companies (or yourselves) that Agile is an effective framework, don’t be afraid to talk about “RISK MITIGATION“.
Think about it this way; The company wants to know early on that there will be a problem, not near the end of the project. This is part of the purposeful transparency of any Agile framework.
Mike Caspar’s Blog
For those of you who are in the Toronto area, you might be interested in a half-day session being put on by Berteig Consulting: an Introduction to OpenAgile. There are two sessions scheduled for Friday Nov. 4 – one in the morning, one in the afternoon. The price is $50/person and at the end of the session, you will be fully prepared to write the OpenAgile “Readiness” certificate exam. The session is being held at the Hilton in downtown Toronto. The session agenda is as follows:
Register now for the Introduction to OpenAgile morning session.
Register now for the Introduction to OpenAgile afternoon session.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
Cross-posted from my personal blog: A Changemaker in the Making
For the past several weeks, I have been helping a small charity solve a dilemma. Because the charity is well-recognized for their good work, they regularly attract volunteers who want to help. Unfortunately, the two overworked staff members are too busy to recruit, train, and manage them. My approach has been to use OpenAgile, an open source system for delivering value to stakeholders, to implement a few simple techniques to help them.
There are several aspects of OpenAgile that fit very well for managing volunteers:
This means people “volunteer” for tasks instead of doing them based on a tightly defined role or having someone tell them what to do. This frees the staff from having to assign work. Instead, they identify priorities and rely on the volunteer’s creativity and personal motivation to do the task in their own way.
When there is more than one volunteer, they work in a team and share the responsibility for the workload. The team of volunteers discuss the priorities of the organization, and decide among themselves what tasks need to be completed. Then, they create and commit to a 1-2 week short-term plan that will deliver those results. Finally, they come back after the 1-2 week period and reflect on what they accomplished. This pattern of action, reflection, learning, and planning is one of the Foundations of OpenAgile.
This means that all people doing the work should be able to see what tasks needs to get done, what is in progress, and what tasks are done. One technique that co-located teams often use is simply posting tasks on a wall using sticky notes. (Check out my OpenAgile Task Wall Prezi) Another cool idea is Card Meeting which works on the same principle, but it can be useful for distributed teams.
The emphasis on learning is perhaps the most important aspect of OpenAgile that aligns with the needs of volunteer management. The Learning Manifesto states that “Learning is the key that unlocks human capacity.” Volunteers are drawn to an organization because of its vision but can get pushed away when they feel they’re underutilized or not able to contribute in a meaningful way. By making it explicit that the volunteer is primarily accountable for learning, the organization creates a safe space for experimentation and innovation.
This is my first post on the Agile Advice blog. In fact, it’s my first blog post ever. Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile. After all, my background is marketing, community relations, and sustainability! Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.
The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.
As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.
One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.
Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.
Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.
These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.
I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.
David D. Parker
VP Marketing and Sustainability
At Berteig Consulting, we used Scrum to run our business for quite a while – about one year. Over that time we struggled with a few different concepts and practices. As a Certified Scrum Trainer, I am very aware that Scrum requires us to use the framework itself to expose obstacles, rather than modifying Scrum to accommodate obstacles. However, over the course of that year, it became more and more obvious that there is something fundamentally different between writing software products (where Scrum is fantastic) and running a business. Scrum, the framework, just wasn’t good enough.
The main problem we had was with the types of work we encounter in running a business. We noticed patterns in the types of tasks we had every Cycle (Sprint). In this article I will look carefully at two of those types of work and then briefly describe the other three types of work.
We discovered that calendar items such as meetings, scheduled public events, and even personal appointments didn’t fit anywhere in Scrum’s Product Backlog or Sprint Backlog. At first, we tried to think of this as an obstacle and force-fit these into the Product Backlog. That didn’t work because that meant we couldn’t always prioritize by value. Even if the Product Backlog had something more valuable in it than the scheduled meeting, we sometimes couldn’t change the dates of the meeting to accomodate the more valuable work. So Calendar Items became a new category of work in addition to the new “features” that were in the Product Backlog. (I say “features” in quotes because we were running a business not writing software.)
We also noticed that we were struggling with applying the concept of the Definition of Done. This led us to explore the concept of Repetitive Work. For example, we need to clean our office on a regular basis – vacuum, water plants, take out trash, etc. If we left that until it became more valuable than anything else on our Product Backlog we would have ended up with a disgusting work environment. So we thought that this should be part of our Definition of Done. The problem then became a more conceptual one: what were we doing that needed cleaning so that it would be considered done? Well of course, it’s simply part of business operations. Cleaning is not independently valuable. We did decide that it was most cost-effective to outsource it, but it didn’t match the concept of Definition of Done as applied to the work in the Product Backlog. That led to an insight: actually, we were looking at a new category of work: Repetitive Items. These are those activities that we need to do to sustain our business and which should become habits, or which should be automated or outsourced.
After identifying Calendar Items and Repetitive Items as types of work, we decided that we needed to look at the Product Backlog more carefully. We decided that we needed to separate features, or as we called it “New Work”, from defects or Quality Items. We also formalized the concept of a queue of Obstacles, which is mentioned in Scrum, but about which is given very little guidance.
So after over a three years of trying to use agile methods to run our business, we have finally come up with a stable and seemingly sufficient set of types of work:
We have written more about our experiences and their results in our e-book: The OpenAgile Primer. If you are trying to use agile methods to run a business or any other kind of organization, please check it out and let us know about your experiences. We hope that OpenAgile will become an Open-Source method that we can contribute back to the world of work and life.
Here are the results from a bit of web research that I just did for a client:
*Mishkin Berteig (http://www.berteigconsulting.com/MishkinBerteig) worked with co-author Kara Silva on a large-scale Agile implementation
It’s generally really hard to get people to talk openly about failure. I assert that Agile itself never fails, rather organizations fail to implement Agile. But that’s for another article. Here are some anonymous stories:
This one includes successes and failures in China:
Another interesting article about the concept of failure:
So cheeky, so true:
Interviews on adopting Agile:
http://www.fastcompany.com/magazine/28/ge.html – GE Jet Engine Factory with self-organizing teams.
http://www.fastcompany.com/magazine/06/writestuff.html – super rigorous software development… the complete opposite of agile!
I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto. We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.
Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me. It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using. So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.
I then suggested that she compose a reply email containing the same set of questions. Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!” I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered. Here are a few:
First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo. Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively. Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team. Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.
(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)
Asking questions in the interest of learning makes it visible to others that you don’t know everything. For some people, this presents a dilemma. What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well. The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage. Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.
Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness. But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway. Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.
Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone. In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention. Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.
To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end. Moreover, it can have a transformative effect on the environment of the team. When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities. Not to mention that most people feel good when they are able to help others. When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.
Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.
Infoq published the video recording of my talk at Agile 2008 titled “Extremely Short Iterations as a Catalyst for Effective Prioritization of Work“.