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.
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.
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.
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…
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!
Certified ScrumMaster Training
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.
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!
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
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.
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.
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.