« May 2005 | Main | July 2005 »
June 30, 2005
Scrum FAQ Wiki Started
Deborah Hartmann, one of the contributors to Agile Advice, has started a wiki-based FAQ for Scrum. At the moment, it is bare of content: please submit questions or answers!
Posted by Mishkin Berteig at 12:30 PM | |
Agile Household Management - Update
So it turns out, in our house, our planning horizon is about one day. Therefore, our one-week iterations were consistently having problems: lots of dropped tasks, but still very busy. As well, the effort of trying to maintain a huge backlog revealed some environmental constraints: we spend a lot of time on yard work, for example.
As a result of these two discoveries, we have moved firmly to day-long iterations. Each day at the beginning of the day we take between 5 and 15 minutes to plan out our days TODO list. Melanie and I each have separate lists. We coordinate our lists throught the master household backlog. Melanie does very well in choosing a TODO list that she can accomplish in a single day, partly because she uses her daily planner to schedule things (estimation). I tend to have a lot of small things fall of the end of my list at the end of the day, mostly because I do not do any sort of estimation or scheduling. I may start.
In my previous entry about Agile Household Management, I mentioned the use of a corkboard. That is no longer being used for tasks. It is now being used for general notices and lists relating to larger tasks. For example, a list of items we need to purchase from Ikea, and a list of repairs we need to hire a plumber to do. My iteration (daily) TODO list is now a piece of paper at the side of my desk.
Posted by Mishkin Berteig at 10:44 AM | |
June 28, 2005
The Agile Workplace
From the article:
The study found that agility -- the ability of the workplace to adapt to change -- has emerged as the single highest priority in the workplace industry. The agile workplace needs to be flexible enough to support many ways of working -- no one size fits all -- and its boundaries need to expand to support work at any time, in any place, with anyone.
The study also examined the effects of the agile workplace. It discovered, for example, that organizational structures tend to be more team-oriented and less hierarchical when it's easier for workers to collaborate across the boundaries of time, space and geography.
Cause or effect? I suspect that there is a positive feedback cycle at work here. As teams and organizations adopt agile practices, they adapt their workspaces to be more suitable. As the workspaces change, the organization is able to more effectively adopt agile practices.
At a team level this is certainly true in my experience. At first, many organizations adopt agile practices without, for example, having the team sit all in the same room. As the team becomes more proficient at the agile practices, it becomes more and more of a burden that the team is not co-located. At some point, it becomes critical for the team to be co-located if they are to become any more efficient. The organization/team then bends itself to enabling co-location. Once the team has found itself a space and moved in, it reaches a new level of effectiveness... until the next environmental constraint is encountered.
Posted by Mishkin Berteig at 07:29 PM | |
June 27, 2005
What If Something Hurts?
If your work is hurt by some environmental, team or technical factor, there are only a few things you can do about it:
1. Ignore it (not advised). This usually can "work" for a short time, but inevitably leads to greater pain in the future. The only time this might be worthy of consideration is if the team has a larger or more immediate problem that deserves the team's full effort.
2. Attack it/do it a lot/embrace it. Develop an exceptional skill in dealing with the problem without eliminating it's root cause.
3. Transfer or expose the stakeholders to it. Be truthful about the situation so that the stakeholders can deliberate on how to effectively address the situation. In this collaborative approach, the team and the stakeholders work to determine the root cause of the problem as part of addressing it.
4. Measure things very visibly. Expose stakeholders to the problem in a factual manner. This method is used where the relationship between the team and the stakeholders is not yet a trusting relationship. This approach can be an effective CYA for both the team and the stakeholders and can lead to greater trust.
Posted by Mishkin Berteig at 11:30 PM | |
June 24, 2005
Big Visible Charts
Ron Jeffries recently posted something to the scrum developers list, where he made reference to his article on Big Visible Charts. It's a good article, and looks at a variety of presentations of metrics in an agile project. It took me back to Edward Tufte's Envisioning Information
As practitioners and advocates of agile approaches, or as people considering the use of agile, the presentation of real status of an effort is crucial. The more of, and the more creative solutions that we can use to present this, the better we can communicate the real business value that the stakeholders are receiving.
Posted by Christian Gruber at 09:19 AM | |
June 23, 2005
Comments and TrackBacks now using HaloScan
Please try them out! And if you like the system, check out HaloScan.com. And let me know in the comments if there are any problems :-)
Posted by Mishkin Berteig at 10:30 AM | |
Avoid Making Your Testing Debt Bigger
At the Scrum Gathering in May, Mike Cohn gave some good advice about testing in software that applies to all types of Agile Work. A very important Agile Work Practice is Test-Driven Work. If you are applying agile to an existing endeavor, there may be a lot of work already completed which does not have tests in place. This is a testing debt: eventually you will have to pay the principle down (build tests) or you will keep paying the interest (fix quality problems).
1. Start by creating tests that are easy. This is the "low-hanging fruit" and it gives the team a sense of accomplishment and progress against what may be a very large and difficult (but necessary) task. This can be done in such a way that it creates a framework that makes the creation of future tests easier.
2. Add to all new work the creation of tests. This is the move to test-driven work. At this point, your testing debt will now be growing smaller as a percentage of the overall amount of work. This standard must become second-nature to the team.
3. Once all new work is being done in a test-driven fashion, it is possible to start paying off the testing debt principle. The team sets aside a small amount of extra time to build tests for work that is already "complete". It is important to focus on building tests for the parts of the work that are most likely to need the tests.
For software, the book Test Driven Development: By Example by Kent Beck is an excellent introduction. I would like recommendations for books and web resources for testing and quality in other fields. Please email suggestions to topics@agileadvice.com.
Posted by Mishkin Berteig at 09:13 AM | |
June 22, 2005
Good Agile Enterprise Resource Site
I have not yet read many of the papers on the site, but Paradigm Shift International hosts a substantial collection of essays and links to other work on the topic of Enterprise Agility. The author of the essays, Rick Dove, has been writing on the topic since November 1994. As I read these essays, I will write up very brief reviews with comments about how his thinking relates to Agile Work.
Posted by Mishkin Berteig at 10:18 AM | |
Agile Enterprise Reference Model
There is a very interesting paper online that presents an Agile Enterprise Reference Model. From the paper:
Sponsored by the Agility Forum, this 1996 reference model project had two principal goals: 1) design a reference model structure that effectively captures and displays the essence of enterprise-wide competency at both proactive and reactive change; and 2) validate the design with a rich, comprehensive example that provides an instructive reference case for an entire enterprise. The purpose is to provide a defining profile with examples for business managers and executives responsible for strategic planning, operational management, and reengineering.
One very interesting part of the reference model is a Change Proficiency Maturity Model. In this model, an organization can be described by its level of maturity in adapting to and creating change. The levels of maturity are as follows (again quoted from the paper):
0: Accidental - Stumble through change, recognition but no awareness.
1: Repeatable - A set of rules for acheiving change become understood.
2: Defined - Rules broadened and performance metrics put in place.
3: Managed - Objectives clarified, rules refined, accountability in place.
4: Mastered - No longer rule based - principles guide action.
There is a logical correlation between these levels and the various aspects of the Agile Work framework. The Repeatable and Defined levels of Change Proficiency match up with the various Agile Work Practices such as Maximize Communication, Self-Steering Team, and Adaptive Planning. The Managed level of maturity matches up with the Agile Work Disciplines of Empower the Team, Amplify Learning and Eliminate Waste. Finally, the Mastered level of maturity corresponds to the Agile Work Axioms: People are Creators, Change is Constant and Reality is Perceived.
Posted by Mishkin Berteig at 03:52 AM | |
June 20, 2005
Meet and Greet Before Critical Meeting
As an agile coach, one pattern of activity that I have found very beneficial is to meet up, one-on-one or in a group of three, with individuals before critical meetings. Critical meetings include training, facilitated workshops, conflict resolution meetings, project launch meetings, or any meeting where there is a lot at stake.
Each one-on-one follows a similar pattern. First, basic introductions. Then, I give a very abreviated life and professional history (married with three kids, grew up as a geek, 9 years doing agile, blah dee blah...). I also ask for a brief professional history from the person I am meeting with and if possible, as a little about who they are as a person. For example, I might ask about hobbies, family or what they consider important outside of work. Then, I check on their knowledge of the subject of the meeting. I get a basic background of how they think they might contribute to the meeting. I also find out how much they are familiar with agile, lean and other related concepts. If they are not at all familiar, I give a very brief introduction to agile work. Finally, I ask if they have any thoughts or questions that might be important for the upcoming meeting.
What does all this do? First of all, it allows me to have a personal connection with everyone in the meeting so that I don't have to try to build that on top of facilitating the discussion at hand. Secondly, it helps map out some of the strengths of the individuals involved. Occasionally, I will encounter someone who has something really unique to offer in the meeting. For these people, I ask them to make a special effort to present their unique skill, knowledge, etc. at the meeting. They may even go on the agenda. Thirdly, the one-on-one meetings provide a potentially safe environment to bring up issues that may be hard to bring up in a group.
I usually budget 1/2 hour for each meeting and they usually start a few days before the main event.
Posted by Mishkin Berteig at 11:56 PM | |
June 19, 2005
De-matrixed Teams
Many large organizations currently operate by creating project teams of people who formally report into other parts of the organization. This matrixed organization is meant to allow people to develop centers of excellence around a specialization and at the same time to implement a system of checks and balances. However, this type of organization also often encourages sub-optimal behavior by narrow performance measures and incentives (narrow to the area of specialization).
Consider using de-matrixed teams if you are finding that people on your teams are having a hard time collaborating, or if people are refusing to do work outside their area of specialization, or if people are doing really well inside their center of excellence but seem to have real problems making projects succeed.
What is a de-matrixed team? A de-matrixed team is constituted by having all members of the team report to a primary stakeholder of the endeavor. It is still possible, and often wise, to maintain centers of excellence, but team members no longer report into these centers of excellence. Instead, the centers of excellence become a source of support for teams that have specific needs (skills, infrastructure, etc.).
Posted by Mishkin Berteig at 11:51 PM | |
June 18, 2005
Management and Trust: a Tale of Two Cultures
Briefly: I have a story to tell of two organizational cultures. In one, called Great Leader Financials, management tends to trust people in the company enough to give them great lattitude in how they get work done. In another, called Rigorous Process Financials, trust all around is low and is compensated for by meticulous processes and documentation. Both organizations are large with many thousands of employees.
At Great Leader Financials, our project team decided we needed to put in place a new server to experiment with some software tools to assist with the work we were doing. One of the team members had recently finished with another project and knew that the other project had a server they were no longer using. He simply contacted someone in management, let them know what was going on, and re-configured the server for our team's use. Within minutes we had effectively transferred "ownership" of the server from one team to another. Several hours later, the server was set up with the new software and we were able to start trying it out.
Regrettably, in a similar situation at Rigorous Process Financials, our project team identified a need for a server to try out some interesting software tools for our project... and then ran into a huge bureaucratic brick wall. It turns out that at Rigorous Process, you can not just re-configure an existing server. One must follow the prescribed process. Unfortunately, the prescribed process requires getting a budget and project approval. And getting project approval involves going through a very lengthy project prioritization process. And small experimental infrastructure projects are always given a very very low priority. Trying "guerilla" tactics would have fared no better. Simply going out and purchasing a cheap computer (say $400 bucks) and brining it in would have only one effect: bringing down the immediate wrath of the IT Operations people as they detected a new server on the network. At Rigorous Process Financials, we do things the right way, or more likely, we don't do them at all.
Posted by Mishkin Berteig at 11:43 PM | |
June 16, 2005
Engaging the Environment
In a recent discussion I had with someone about the Agile Work Axioms, he mentioned that he thought that "people are lazy by nature". Here is my brief response:
I don't totally agree. Those who are motivated for whatever reason to do something will be "not-lazy", and those who aren't motivated will be "lazy". But the fact is, that I don't think laziness is a fundamental truth about human nature. I think it's a consequence of how engaged we are with our environment, which in turn is a result of both our internal state, and how attractive our environment is. Television is a great example: it is so engaging that we will sit around doing nothing even if it becomes physically quite uncomfortable. Normally, laziness is associated with avoiding discomfort.
In terms of engaging with our environment, the three Agile Work Axioms define a system of engagement:
Posted by Mishkin Berteig at 10:44 PM | |
June 15, 2005
A Student Documentary Film Project
In January of 2005 I was invited to give a one-hour introduction to Scrum to a college media arts class. The class had one group project: to create a student documentary film on some topic. The instructor and the class used an adaptation of Scrum to manage the work of creating the documentary. Some key features from Agile Work included Self-Steering Team, Iterative Delivery, and Adaptive Planning. The following is one student's reflections on the project. The student who wrote the following was, during my presentation to the class, acclaimed as the best person to be the Scrum Master.
“The whole documentary process has been an enlightening challenge.First there was the process to find a consensus on a direction. Possibly the first real challenge as a group. As scrum master there were some great personal challenges. I am not a big fan of teamwork. I see it's value but I have always worked independently and lived or died by my own efforts. There are huge issues of trust and success when you start with a group dynamic. The trust goes both ways. What if I let the group down because of my health or slower technical skills?? When you work independently you can set your own schedule. Will the pressure of letting down the group be enough to motivate the individuals?
SO the second big learning process for me was to be part of a team.
As scrum master I needed to keep myself focused and everyone on track without being a too pushy. NO one has any real obligation to me or anyone else on the team so setting a manageable pace, problem solving as an individual and as a team was another vital part of the process.
The whole concept of iterations kept things in manageable sections, that was a huge contributor to keeping a manageable goal in site when we were all feeling overwhelmed by the load of all of our courses work. AN interesting observation was that I think there were times when what we were doing in documentary was relatively minor but the fact that we were accountable for it everyday made some people feel overwhelmed. I certainly stand to be corrected but I think because we became such a good team that there was (and still is) a sense of the collective workload.We all improved our technical skills, me particularly. I still have lots to learn but my confidence level is much higher.
There is a lot of respect shown for everyone's work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn't seem to be a lot of ego attached individually. We are each willing to recognize each other's strength's and weakness without rude or critical.
Overall this has been a positive process that is all about teamwork, individual strengths and respect. Garry [the instructor], you have been terrific about leading from behind! There were many times (and still will be) when we know we have a direction but don't know how to get on the road exactly. You share your professional experience in such a way that we feel like we went searching for buried treasure and made the map ourselves.
I hope to finish the process and keep the momentum to an exciting finished product.” –Sharon
The project was indeed completed successfully! Other students in the class also provided very positive feedback on the use of Agile Work methods.
Posted by Mishkin Berteig at 11:54 PM | |
June 14, 2005
Collocate the Team
Collocation of the team is used to improve communication efficiency and to allow the team to learn to be more collaborative. Perfect collocation would have all stakeholders and work performers in the same work space (e.g. a large room) during all working hours. This level of collocation is not usually possible, so adjustments are made.
Collocation reduces wastes associated with waiting, movement, and inefficient communication. Collocation increases learning and feedback and assists with team empowerment.
Collocation can present challenges to people used to working on their own. For these people, a careful consideration of how to accommodate their working style is important, but more important is helping them to understand the need for and benefits from collocation. As this understanding grows and as the team starts to produce noticeable results, most people start to enjoy the close working environment.
When perfect collocation is not possible, consider part-time collocation, video conferencing, having a decision-making proxy represent the stakeholders, getting rid of closed offices, moving into open or shared work spaces or collocating part of the team.
I typically hear a great deal of positive feedback from teams that were previously not collocated after they come together in a common space. For example: "I don't have to spend hours dealing with email anymore - it takes a few seconds to lean over and ask a question and get a response." "Meetings that used to take half an hour to organize on people's calendars now happen spontaneously." "I can work much more efficiently because the people who I need to collaborate with are right there. No more emails, phone calls, scheduling, and pestering."
Posted by Mishkin Berteig at 09:27 PM | |
June 13, 2005
Reality is Perceived - So What?
Results are necessary to reach a goal. Work is done to produce results and reach a goal. Therefore, any work done that does not produce results that contribute to the goal is wasteful. The degree to which a result of work contributes to the goal is the degree to which that work is valuable. However, since reality is perceived, it means that the stakeholders' perception of the results is of paramount importance. If a team produces a result that the stakeholders do not find valuable, then at that time, it is not valuable. This is both obvious and subtle. If the stakeholders have an articulated set of values, then it is easier for the team to produce results that satisfy those values. However, it is often the case that stakeholders will also have unarticulated values. These unarticulated values are just as important. Agile Work attempts to use various disciplines and practices to elucidate, draw out and make explicit the values of the stakeholders so that the team can produce results that are satisfactory.
Posted by Mishkin Berteig at 10:01 PM | |
June 12, 2005
A Brief Note About Types of Backlog Items
In very broad strokes, there seem to be three categories into which backlog items can be put:
1. End Results - new functionality or capability that provides direct value to stakeholders.
2. Infrastructure Investment - work that is done to support the creation or delivery of end results but which does not directly provide value.
3. Debt Reduction - work that is done to eliminate barries to the creation of end results.
There are also some types of items that (typically) are not put on backlogs:
- Ongoing Tasks - tasks that are repeated on a regular basis.
- Constraints - descriptions of the qualities of the end results.
- Milestones - events or dates that define the transition from one state to another in an endeavor.
Posted by Mishkin Berteig at 11:35 PM | |
June 10, 2005
Self-Steering Team
Team self-steering is accomplished through a structured meeting that is used with regularity and several times or many times during an iteration. This type of meeting is used in order for the team to have a structured method of sharing critical information. Team self-steering is often done with a meeting called the “daily scrum”.
The team self-steering meeting involves each team member answering the following questions:
1.What work have you completed since the last meeting?
2.What work do you commit to complete before the next meeting?
3.What barriers are you encountering that are hindering your work or the team?
Generally, the answers to these questions should be kept brief and concrete. For example, in reporting work completed, the report should name tasks that are completed. Some teams who are using an information radiator for their task tracking will physically manipulate the tasks in some way to indicate they are complete. Team members must avoid getting into details during this meeting. It is not a working meeting where any decisions are made or work performed. Even discussion among team members should be deferred to after the team self-steering meeting is complete. A future entry will detail some of the types of barriers that teams typically come across.
One member of the team is specially empowered to track and eliminate the barriers. In the Scrum methodology, this person is called the Scrum Master. This person must have a pro-active and independent personality and have access to the rest of the stakeholders. The person eliminating barriers should remain the same over the course of an endeavor if possible. Every barrier mentioned in a team self-steering meeting should be resolved before the next meeting if possible. If that is impossible, the unresolved barriers are reported to the team and the team decides for itself how to work around the barrier.
As a rule of thumb, this meeting occurs every day at the same time of day. With a team of about eight people, the meeting should take less than fifteen minutes. Stakeholders who are not committing to perform work may observe the team self-steering meeting, but may not otherwise participate.
Some teams may be in a situation where they have people filling roles as managers, project managers, team leads or administrative assistants. All these roles can be integrated into a self-steering team. The key to doing this is that all team members must be willing to move beyond the strict definition of their role, and participate with equal responsibility for delivering results. For some people, moving outside of a defined role is very uncomfortable, or undesireable. These people may become effective team members with careful coaching.
In general, teams that are very new to self-steering benefit from external coaching that provides insight into teamwork, organizational culture, and personal development. All three disciplines are necessary components of creating a high-performance self-steering team.
The team self-steering meeting amplifies learning and feedback, enables responding to change, helps empower the team, emphasizes individuals and interactions as well as valuable results. This practice is critical to agile work.
Posted by Mishkin Berteig at 05:40 PM | |
June 06, 2005
Agile Household Management - Update
In a previous entry, I described some problems that we are having in using agile work practices in our household management. We have put up a cork board in our hallway in order to hold our tasks. It's lovely! It also is really practical. As we complete the tasks, we are taking them down and throwing them away. As might be expected, this very physical closure on tasks is very satisfying. For myself, the visible tasks has greatly improved my awareness of what needs to be done. I find myself checking the board a few times a day at least. It remains to be seen if this will help us become more accurate in our selection of work for an iteration...
Posted by Mishkin Berteig at 10:42 PM | |
June 05, 2005
Scrum Evolution: What's it all about?
Love it or hate it, the Agile 2005 Conference reviewers thought the paper below was either a major innovation or a gross violation of the principles (dogma) of Scrum. It's motto is innovate or die and only the paranoid survive in the global economy. Does it show the future of Scrum? Well the paper was accepted for presentation at Agile 2005 and many people have asked for the real bits (all 27 pages) before I chop it down to the required 10 page IEEE paper. It could take you to CMM Level 4 or beyond. Decide for yourself whether this paper should be burned or nailed on a door somewhere!
Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects
Certified ScrumMaster Training
Patientkeeper, Inc.,
Abstract
Scrum was invented to rapidly drive innovative new product to market. Six month releases used to be a reasonable time from for an enterprise system. Now it is three months for a major new release, one month for upgrades, and one week for maintenance releases. The initial version of the Agile Scrum development process was designed to enhance productivity and reduce time to market for new product. In this paper, one of the inventors of Scrum goes back to Scrum basics, throws out preconceived notions, and designs Advanced Scrum using multiple overlapping Sprints within the same Scrum teams. This methodology delivers increasing application functionality to market at a pace that overwhelms competitors. To capture dominant market share in 2005 requires a metaScrum for release planning, variable length Sprints, overlapping Sprints for a single team, pre-staging Product Backlog, daily Scrum of Scrums meetings, and automation and integration of Product Backlog and Sprint Backlog with real-time reporting. A practical example of Advanced Scrum describes how mobile/wireless product teams implemented Scrum process automation during 2000-2005. Administrative overhead for over 45 enterprise product releases a year was less than 60 seconds a day per developer and less than 10 minutes a day for a Project Manager. While Advanced Scrum is not for the uninitiated, the future of Scrum is still Scrum, just faster, better, and cooler.
Posted by Jeff Sutherland at 11:42 AM | | | TrackBack
June 04, 2005
Does Agile Software Development do away with Business Analysts?
I've been exploring career directions - and I must admit, this question has haunted me for a while. Fearing the answer to be "yes", I forged ahead, wading through blogs, and meeting with colleagues to find out how they work.
My conclusion: Agile Software Development transforms the role of the Business Analyst.
But this is not surprising - one of the main things that happens when working Agile is a realignment of responsibility with accountability. Customers become responsible to state and prioritize their requirements - and Agile processes hold them accountable for these things. Development teams become wholly responsible for delivering the required functionality - and are held accountable for its quality.
The Business Analyst may find herself floating between these two responsibilities. She must navigate this territory with care - our old way of working often meant taking on accountability from these two groups, a step backward when working Agile. I believe that the BA can become a facilitator - enabling Customers and or Developers to get their jobs done. In some organizations, this role is called "Agile Coach", and may be played by a BA, a Developer or anyone passionate about enabling the work of the team. While not every team needs a coach, it can be an important role - particularly when newly adopting Agile.
There is a balancing act required to do this... my blog covers a few scenarios derived from discussions with my Toronto colleagues.
A BA not interested in coaching could also retrain as a Developer or move into the Customer camp as a Product Owner or Product Manager. Fear not, there are still many ways to help build great software!
Posted by Deborah Hartmann at 08:16 AM | | | TrackBack
Lean Construction is Agile
I love Hal Macomber's blog "Reforming Project Management". And while he writes from a background of Lean Construction, his posts apply across other domains as well - I find they often resonate with the work I do in Agile software development. His site also includes articles and web conferences, and has an RSS feed so you don't miss his short, salient posts. Have a look!
Reforming Project Management
Hal Macomber, Project Reformer, explores the evolving theory and practices of lean project delivery
Posted by Deborah Hartmann at 08:04 AM | | | TrackBack
June 03, 2005
Agile Manufacturing References
Agile manufacturing: is the ability to accomplish rapid changeover between the manufacture of different assemblies. Rapid changeover is further defined as the ability to move from the assembly of one product to the assembly of a similar product with a minimum of change in tooling and software. Rapid changeover enables the production of small lot sizes, allowing for `just-in-time' production.
The link is to a page with a list of links to other pages about agile manufacturing. Lots of good stuff to be found there.
Posted by Mishkin Berteig at 11:46 PM | |
June 02, 2005
A Little Something from The Theory of Constraints
The Theory of Constraints or (ToC)[Google] is introduced in the book "The Goal">The Goal" by Eli Goldratt. At its most basic level, the theory of constraints posits that there is only one thing right now preventing your team from going faster. It is the weakest/slowest link in a process or procedure.
How do you find that one thing? There are various possibilities depending on the sort of work environment. One way, that is appropriate to a manufacturing-like process is to identify the Work in Process (WIP) pileup. If you are working in a more human-skills based process, then ask "if you can only hire one skill set, what would it be?"
In an agile process framework like Scrum, there is constant discovery of the constraints (although possibly not the one specific constraint that is slowing the overall process). This discovery is encouraged by the Scrum Master and is exposed by team members as they participate in their daily "scrum" status meeting. An important feature of this meeting is that the team members identify any barriers to the performance of their work. The Scrum Master is then responsible for removing the barriers that are identified.
In organizations that are very paper-documentation oriented, often approval gates are one of the worst constraints in a process. Those who must approve the team's movement to the next step must receive the documentation they need, then find the time to read it, then find the time to formulate their decision, and then find the time to communicate it to the team. I have been in environments where this can take a few months (I'm sure some organizations are worse, and many are better than this). During this time, the team is essentially idle.
Another typical problem exists in organizations that have gone through several rounds of layoffs in a short time period. In this situation, often the constraint is due to an unbalanced skill distribution. The organization may have very few people with a specific critical skill. The only way to remove the constraint (and speed up) is to add more people with the skill either by hiring or by training.
In general, because of their short iterations, and the resulting amplification of learning, agile teams tend to expose many constraints in the organizational environment. This can be a cause of backlash against the agile team.
Posted by Mishkin Berteig at 10:01 PM | |
June 01, 2005
Adaptive Planning - Using a Backlog of Work
In order to respond to change, plans must be made so that they can be adjusted... and then they must be changed! The agile approach to this is to use adaptive planning with a backlog of work packages or tasks.
In order to create this backlog, an overall result or goal is divided up into work packages. For example, a large company may divide its work into projects where each project becomes a work package. On a smaller level, each project may be divided into work packages, each of which represents some value to the overall project goal (note, this is different from a traditional project work breakdown structure). A third example is in the creation of a book, each chapter may be a separate work package. A work backlog can contain anything that stakeholders consider even remotely relevant to their goals for this endeavor.
Next, work packages are prioritized and listed in strict decreasing priority in a backlog. In this backlog, no two packages have the same priority. Ideally, a single person is responsible for maintaining this backlog and determining the priority of work packages. Collective maintenance of this backlog can be a source of much extra work and even conflict. The person responsible for maintaining the backlog must be trusted to take all the stakeholders' interests and produce a reasonable priority list.
Each iteration, the team collaborates with the stakeholders to choose some number of work packages to work on and complete. If the team does not think it can complete a work package in a single iteration, it should be broken into smaller packages (remember that iteration length is not flexible!). The team is responsible for committing to the work so they have the final say on how much work they can accomplish during an iteration. No other stakeholders should pressure the team to commit to more.
Inside each iteration, the team breaks the work packages into smaller tasks and prioritizes them. Based somewhat on task priority, individuals in the team choose tasks to accomplish and work on them. It is very important for team empowerment that tasks are neither defined nor assigned by people outside the team.
At the end of each iteration, the work accomplished is demonstrated to the stakeholders. Based on these demonstrations and the lessons learned by the team, the remaining work packages are re-prioritized. Packages in the backlog can be added, removed or changed at any time, but the team's work can only be adjusted between iterations.
Using adaptive planning with a backlog in combination with iterative and incremental delivery enables the principle of responding to change. It is also a method to improve team empowerment and amplify learning.
Posted by Mishkin Berteig at 06:45 PM | |