Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
“I now can see why Corporations have such a hard time identifying the Scrum Master in their organizations. Scrum Masters basically don’t fit either category, yet most corporate hiring is done based on hiring of “leaders” and “managers”.”
For the complete text click here
We have delayed announcing our winter 2012 schedule until now because we have been working on a new platform for listing our courses and creating a community environment for people who have taken our courses. So, without further ado, I would like to offer to you: World Mindware!
Since we are agile ourselves, this site is still very basic. We have our list of courses and you are able to register for courses. However, we welcome feedback of all kinds including bug reports, suggestions for improvements or requests for assistance. Please contact firstname.lastname@example.org if you have any feedback about the site.
I’ve recently joined Berteig Consulting Inc., and we are wrapping up our first cycle as a new team. The last two weeks has been an extraordinarily rich experience for me in a multitude of ways.
The time I’ve spent reviewing various online and published Agile reference materials, thinking deeply about the concepts in the Agile Manifesto and Principles, studying some in-house materials and portions of different books about agile coaching and retrospectives has been really useful to my deepening in the concepts surrounding the framework of Agile. Even more helpful though has been the fact that I have had the opportunity to complement this reading and studying with action and engagement with our clients, and that our team has been so open to the reflections I’ve shared and has shared their own. Previous experiences have taught me that familiarity with resources and guidance, without practical application, can be limiting and create an over-intellectualization of concepts that, when divorced from action, can create an artificial version of reality, and that makes me even more appreciative for the time I’ve been able to spend interacting with clients and thinking about what I’ve been reading about and how this would be applicable to their teams.
Our team regularly articulates and works to apply concepts we think are foundational to growth and transformation, such as truthfulness, consultation, and agility in thinking and action at the individual and group level. I’ve found that our ongoing communication in our team room and reflection throughout the day has been instrumental in creating a space that is open and forward moving for us.
I’ve also realized a lot of factors have contributed to the culture of learning we are continually developing in our team, including our openness and honesty during progress meetings, our efforts to use consultation as a guide and instrument when we’re trying to make decisions, the actions we take to complete a task, and our readiness to respond to change. I think we’re also all really aware in our team how important our approach to the process of learning is. I’ve found this manifested in different team members in different ways: experienced ones practice coupling expertise with humility, others display incredible levels of patience and servitude to the team, still others animate the group with high levels of joy and kindness.
We also each seem to have a very conscious appreciation for the new culture we are trying to create within our team, which will help us in accompanying other teams to develop as well. Personally, I am continually striving to transform my actions to reflect what I learn through each experience each day and feel that the individuals on our team are doing the same. We increase our understanding of how to transform our own actions and those of the team as a unit as we apply what we are learning simultaneously to areas and interactions beyond ourselves. From what I’ve seen so far, transformation is a key concept with every team we are engaged with, and I think that we can contribute to that process a lot more if we are also always trying as a team to do the same.
The spirit of collaboration I have experienced within our team and with our clients has been really uplifting to me and for that I thank each of you, my collaborators, for your contributions and all that we have been able to do and learn together.
The concept is simple: there are six levels of planning in an organization, often represented as layers of a metaphorical onion. In the agile planning onion, strategy is the outermost layer. This is meant to indicate that it is the driver of all the planning in the inner layers, which have shorter time horizons, down to the daily planning that occurs in the Daily Scrum or the Daily Standup of the agile teams.
Culture is Missing
The agile planning onion is a reasonable metaphor, but it has a serious limit: culture is missing. Many of you will have heard the quote “Culture eats strategy for lunch [or breakfast]” (attributed to quite a number of different people – I’m not going to sort out who was the original). How do we represent culture on the onion? Is it a seventh layer on the outside? Maybe, but for most organizations, culture is not planned.
Single Loop Learning
The main problem with the planning onion is that it gives no indication that the planning cycles deal with anything but the product / business side of the work. This implication of single-minded focus gives us permission to limit ourselves to improving our products. This is learning, but it is limited. It is sometimes referred to as “single loop learning”. We make improvements, but never question our underlying beliefs, habits or goals. All improvement (and planning) is within the narrow guard rails of a product mentality.
Double Loop Learning
Culture both surrounds the planning onion, and cuts right through it (nice way to extend the metaphor!) The problem with a visual metaphor that does not include culture is it means that culture remains unconscious. As individuals we might, from time-to-time, find that the organization’s culture clashes with our own expectations, habits or beliefs. But other than this occasional dissonance, we are like onions in dirt – completely unaware of the dirt, yet completely utterly dependent upon it for growth (couldn’t use “fish in water” because that would have introduced a different metaphor – I’m trying for consistency).
In the best agile transformations, individuals, teams and organizations become aware of their culture and consciously work to change it. This is usually due to a strong clash between their current culture, and the behaviors, norms and attitudes of a embryonic agile culture. In Scrum, we find impediments and remove them. In OpenAgile we look for learning about product, process and people. This is, again, roughly speaking, double loop learning… it is learning about learning and applying this to our belief systems, our habits and our attitudes.
Transformation vs. Adoption
Those who share the agile planning onion model, probably don’t realize its limits. I would like to strongly encourage those who use this model to consider re-framing it in terms of culture and organizational learning, rather than planning. I’m terrible at diagrams – I hope someone out there will consider creating a new compelling Agile Learning Onion diagram to show that agile is about Transformation, not merely adoption of planning practices.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
I. Agile Volunteer Team Process
- The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
- Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
- Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
- The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
- Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
- When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
- When a volunteer completes a task, they move the task into the “done” column.
- There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
- What did I do last week?
- What will I do this week?
- What did I learn/observe?
- What obstacles, if any, are affecting my ability to do work?
- New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
II. Communication Tools
- Login and read new messages
- Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
- Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
- Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
- Get work done:
- Move the task on the wall to in progress
- If the task came from an email, label the task with your name
- When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
- ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
- By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
- FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
- Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
- Task Written & Posted – apply this label after you write up the task and post it on the wall
- Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
- Website – these emails are relevant to website updates
III. What is 60/40 Time?
- Belief in the mission of the charity
- Desire to “give back”
- Meet new people
- Make new business contacts
- Invited or inspired by another volunteer or staff member
- Improve resume
- Learn new skills
- Benefits such as free events
I have started composing a series of articles on my blog A Changemaker in the Making that are intended to briefly explain how to apply different agile practices to the work of social innovators, non-profits, charities and volunteer organizations.
The first article covers Self-Organizing Teams an important consideration for organizations that want to use their people resources more efficiently and to create a culture of empowerment.
The second article explores The Agile Workspace and ways to create an environment that is conducive to fruitful interaction.
A close associate, David Parker, has written a great little article about the use of agile methods in volunteer management.
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:
1. Self-Organizing Behavior
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.
2. Shared Responsibility for the Workload
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.
3. Visible Tasks
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.
4. Learning Manifesto
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.
Christian Gruber, a Googler, an agile guru and an Aikido practitioner clears up some important mis-understandings about Shu-Ha-Ri as applied to both learning Agile and learning Aikido: http://bit.ly/bqgvZS . Strongly Recommended!
Isráfíl Consulting Services is pleased to announce our upcoming:
Software Developers, Technical Architects and Lead Developers for teams that currently use or are intending to use Agile methods such as Scrum, Extreme Programming or OpenAgile will benefit from attending this course.
After completing this course you will:
- increase your development productivity
- be familiar with basic disciplines to create well-tested, defect-free code
- be able to integrate successfully into Agile teams
- understand what makes healthy, maintainable code
- receive a Certificate of Attendance
- receive $100.00 discount on a 3-day Scrum training and certification course by our partners
- 2009-06-22: 2-day Agile Software Engineering Practices – Ottawa, ON $1450.00 CAD [16 spaces]
- Register by June 1 and get the early-bird price of $1,250.00.
- 2009-06-25: 2-day Agile Software Engineering Practices – Markham, ON $1450.00 CAD [16 spaces]
- Register by June 1 and get the early-bird price of $1,250.00.
Register!: http://www.israfil.net/publictraining/registerCourse Details: http://www.israfil.net/publictraining/coursesClass Schedules: http://www.israfil.net/publictraining/scheduleFor more information, please e-mail us at: email@example.com
In Scrum, there is a concept of the “Definition of ‘Done’” that is used to understand what teams produce every Sprint. Unfortunately, it is not well understood, nor is it consistently applied. Part of the problem is that the name of the concept is misleading. Every time we do coaching or training in organizations, we spend an inordinate amount of time getting this concept across clearly. Recently, one of our coaches, Travis Birch, had an insight about the name of the concept. The word “definition” makes us think of something static and permanent. Definitions don’t normally change. However, in Scrum, the definition of “done” is always changing. Doneness is not something that we get perfect at the start, rather, teams develop their capacity to deliver more and more each Sprint… and not just in terms of features. As I explained in another article called Four Methods of Perfecting Agile, the definition of “done” is something that can and should grow over time.
So what can we do? Can we rename the concept? The concept is really a snapshot description of the activities and attributes that a team puts into a Sprint’s worth of work. For example, at first a team might not be writing automated unit tests. Therefore, automated unit tests are not part of the definition of “done” – a snapshot of their work at the end of the Sprint does not include automated unit tests. Then in a retrospective the team decides that they need to create automated unit tests. They do so in the next Sprint. Now, automated unit tests are a part of the definition of “done”. Finally, a few Sprints later, one of the members of the team attends Agile Software Engineering Practices training [shameless plug] and decides that they should start doing test-driven development. The team learns how to do this and from now on the definition of “done” includes test-driving all production code.
<strong>A New Name</strong>
Let’s try another name for this concept: the “Expanding Benchmark”. I think this term much more accurately conveys the sense of the concept. It is expected that this concept is not static, rather, as the team overcomes obstacles, automates things, learns new skills, and gains new trust and authority, that their work will expand. And specifically, we are expanding the benchmark of what activities and attributes of software are delivered at the end of each Sprint.
So – let’s get rid of the Definition of “Done” and start talking about a team’s Expanding Benchmark. What sayest you?
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.
Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning – disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment – opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders – engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control – mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change – processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.