I just finished reading an excellent article about a UCLA prof who, for his game theory class, allowed the students to cheat
I strongly recommend reading this because this points to one of the big cultural barriers to using Agile methods effectively: we are focused on individual performance instead of the outcomes of a group (team) of people!
Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)
Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards
Process:
Notes:
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes
The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.
The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.
Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.
For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff. The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”. The basic approach follows these steps:
Of course, the details matter. The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix. I highly recommend using these to get started. If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself. Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes. You should also let the team know that you will be basing performance reviews on how they improve their skills.
The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this. As a manager, you should review each team members’ goals for development and provide mentoring support when needed. At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set. Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.
I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment. In particular, individual performance reviews should not be tied to bonuses. If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.
Every once in a while I’m reminded of the very important question: WHY?
If you are considering SCRUM, XP, Lean or any other Agile Framework, or if you are considering using OpenAgile which is an Open Learning System, you will be changing the organization.
Many people think they can do “Agile in a bubble” and therefore not interact with the rest of the organization. You will likely find that you will quickly run into obstacles to using the Framework.
Just the iterative process alone will change the way stakeholders interact with teams, meeting rooms are scheduled, vacation schedules, communication requirements, team spaces and/or seating, the responsibilities of stakeholders, and even the interactions between team members and other departments. Because of this, working towards Agility WILL change your organization.
You may start out with an aggressive framework such as XP(Extreme Programming), or something a little more gentle such as Kanban or Lean (which let you start out as you are and visualize your process). However, please don’t kid yourself; you will eventually need to change the way things get done in the company.
Whether you are the OpenAgile Growth Facilitator, a Scrum Master trying to introduce Agile from the grass-roots, or if you are the CEO or CIO trying to introduce change from that level, you will eventually need to address the WHY for the change.
Managers and employees alike need to know why they are being asked to leave their comfort zones. In some cases they will be going against everything they have learned in the past about people management or how they should work. They need to know the reason.
Whatever level you are in at your company, please be ready to explain why you are making the change to an Agile Environment. Something like “to be more efficient”, isn’t really going to cut it.
I could think of many other reasons. You should have your OWN reasons.
If you started an adoption or transformation a while back, it’s a good idea to restate this every once in a while (if even for yourself). It will remind you why you are continuing to improve and learn every iteration.
Asking yourself once in a while will also allow you to improve your message which will likely change slightly over time as the market and your environment changes.
Please, go home TONIGHT and ask yourself WHY are we transitioning or continuing to work towards being more agile. You will need to answer this for others more than once as you continue on your journey.
If the answer to yourself is “this is our last chance to make sure we don’t disappear as a company”, that revelation is a good one as well, and you will know why you need to stand strong on the changes you are making. Either way, it all starts with the same question.
Please make sure you always know the answer to the question “Why?“.
References:
OpenAgile, Growth Facilitator
XP (Extreme Programming)
SCRUM
Kanban, Lean
Transforming organizations: check out the Stoos Network. Wish I had been there! Some of my favourite people were there!
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
Mike Caspar’s Blog
Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?. From his question:
While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.
In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later. He describes five types of people in relation to how they adopt new products:
This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.
Implications of the “Chasm” Model
An organization attempting to do an Agile Transformation [Kotter's 8-Step Change Model] should understand how to use this model to ensure long-term success. This diagram illustrates the concepts (click on it to see it full size):
First, the organization should start the transformation by finding the innovators and early adopters. These people can then be recruited to run the initial pilot projects. They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility. If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment. Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.
In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups. These people will tend to drag on the results of the pilot projects. This is a common mistake in running a pilot program and leads to discouraging results. One way to help filter between these two groups is simply to ask for volunteers for the pilot projects. Innovators and early adopters will be much more likely to volunteer for a new initiative.
After the pilot projects have shown some good results, the next step is to go the general roll-out. In this step, you are now working with the early and late majority. These people need much more substantial support for a change of this nature. They will require intensive training, and hand-holding in the form of coaching and mentoring. This hand-holding can come partially from your innovators and early adopters. Some of the participants in the pilot projects will have the desire to share their success. From these, you need to carefully select and prepare a few who will act as internal coaches. If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.
The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated. This evidence partially comes from your pilot projects. However, this may not be sufficient. There are two other important sources of evidence for this group: the leadership team and external experts.
The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team. The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar. As well, this “Agile Transformation Team” must make itself very visible during the general roll-out. This can be done with communication and by taking up visible residence in a central conference room or bullpen. As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.
The second source of evidence comes from external sources. Published case studies are one valuable source. However, there is a huge value in a visible management investment in external support from recognized experts. This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like. When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.
The final stage of a roll-out is to deal with the laggards. For the most part this is a do-or-die proposition for these people. Either get with the program and engage like a committed employee or leave the organization. If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.
For some organizations, this transformation process can take many years. An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years. Often it will be longer. Good luck on your agile transformation effort!
HP Enterprise Services - UK; Various locations (Newcastle upon Tyne, United Kingdom)
HP is seeking Agile Thought Leaders to provide:
Mentoring, Coaching, Training and Assessment internally and to customers.
Our Agile Leadership:
Desired Skills & Experience
Attributes of an AgileCoach:
For clients with large, complex operating environments, HP Enterprise Services provides end-to-end IT services in applications, business process, and infrastructure technology outsourcing for increased productivity, innovation, and security so businesses can plan for future growth and governments can efficiently deliver citizen services.
Mike Caspar has another great post, this time about being truthful about the challenges of working in a high performance team environment.
A few weeks ago, David Parker and I had a conversation about some of the differences between Scrum and OpenAgile. We hit upon one really interesting thing: Scrum strongly emphasizes that it is a purely empirical approach to doing work… and OpenAgile does not make that claim. In fact, OpenAgile, while it includes empiricism, is definitely not an empirical process framework.
Ken Schwaber has long been adamant about empiricism with his phrase “Inspect and Adapt” which is the core of Scrum. All the artifacts, meetings and roles of Scrum are meant to be supportive of the inspect and adapt approach in a product development environment. A Scrum self-organizing team inspects and adapts on the product it is building. It inspects and adapts on the obstacles that arise as it does its work. It inspects and adapts on all the organizational processes, technical tools, team dynamics,… everything! This is Good.
But Scrum, in its pure empiricism, also lacks something.
OpenAgile has components of Scrum’s empiricism. Certainly, OpenAgile owes a great deal to Scrum. The concept of “Systematic Learning”, one of the foundations of OpenAgile, is similar to Scrum’s empirical framework. The process structure of OpenAgile is also similar to that of Scrum with short cycles of work delivering value on a regular basis. The main difference comes from a simple concept: Guidance.
In OpenAgile, guidance is a critical component of systematic learning. Guidance allows someone outside the team to intervene. This might be a manager, a stakeholder, a family member… anyone who sees things from an “outside” perspective. It might also be someone within the team pulling in guidance: asking for advice, doing a web search, reading a book, or even meditating in the hope of inspiration.
In Scrum, there are some very strong boundaries around outsiders providing guidance. No changes mid-sprint. All requests for work go through the Team’s Product Owner. The ScrumMaster “protects” the team from outside interruptions. ”Chickens” cannot participate in the Daily Scrum. The team self-organizes with individuals volunteering for specific tasks. Team members discard all organizational titles when working within a Scrum team. All of these boundaries support a pure empirical approach to working. They also provide a form of safety for the team. This safety is deemed necessary with the implication that stuff from outside the team is dangerous.
In OpenAgile, guidance comes to the team through the conduit of love. Yes… love.
The team develops a love for its work. This love then opens the team members to guidance. Think of the opposite: if I hate my work, I’m not likely to be interested in taking any advice about how to do it better. If I love my work, I will always be seeking ways to improve it.
Of course, love is not binary. It’s not on or off. In that continuum, the more an OpenAgile team loves its work, the more receptive it will be to guidance. The more receptive to guidance, the more sources of guidance will be “safe”. And the less reliance on pure empiricism will be necessary.
Let’s be frank: pure empiricism, in its most extreme form, means that Scrum teams would re-invent things that may have already been invented many times before. In the Scrum community, the most obvious example of this is the Agile engineering practices that come from Extreme Programming. Scrum teams seem remarkably resistant to adopting these practices at the outset… despite the fact that eventually most Scrum teams working in software succeed or fail based on their eventual adoption of these practices. Scrum teams are often left without the guidance that XP practices can help them. Instead Scrum teams seem expected to re-discover XP practices on their own.
For what it’s worth, I don’t think that Scrum is fatally flawed. In fact, I think that in some environments, where teams truly are unsafe, where people tend to hate their work, where dysfunctional bureaucracy is deeply embedded in the organizations culture… in these environments Scrum is actually the right place to start. Scrum is great for product development in high-crisis situations: save your product with Scrum!
OpenAgile, by accepting guidance into its framework, allows teams to progress rapidly when they can leverage other people’s learning. Scrum does not dis-allow this, but it sets up an environment where the team culture tends towards the “Not Invented Here” syndrome. OpenAgile puts teams on the other path: the path of allowing for greater and greater learning from others.
Inevitably, there will be some change to your team. Someone will leave or perhaps you will have new members joining you.
Either way, you will be asked the question “Where should I sit?”.
Do not take this question lightly. You have the opportunity to make significant changes with the addition or departure of a team member.
There are many different types of personalities in a team. Because of this, you cannot realistically expect the same personal interactions between people sitting next to each other.
More importantly though, it is your responsibility as a Scrum Master, Mentor or Coach to consider the positive adjustments which can be made during this great opportunity for change.
A simple example to get you thinking about this could be….
Trying to talk to the developer who does not ask for assistance, may help. However, why not consider using this opportunity to solve this problem in a different way.
If the developer is moved to a more central location, they will not be as separated from the group. Perhaps this would give them more opportunity to ask for help, increase their communication level with peers, and if you are lucky, the other team members will more easily recognize that this is happening an spur this person on to get them to ask for help.
So, where do you put a new developer ?… Certainly not off at the end by themselves. The new person will feel isolated, and will have a harder time integrating.
The team is already a very close unit and has gone through the team development stages of Forming, Storming, Norming, and Performing. With the addition of the new team member, this cycle will start again and will make it even harder for them if they are on their own at the end of the seating layout.
Reminding the team of the four stages of team development before a new person comes on board can be a big help. It reminds all team members of how hard it is to integrate new members and the likely result of the addition.
Many people can get attached to their desks or workstations. Therefore, moving people around in a traditional environment can be a painful experience. In an Agile team, life is about change, adapting, adjusting to what is happening and making positive changes to improve productivity and enjoyment.
As team members move locations, they will learn different skills and ideas from the person sitting next to them. It will also be common place to adjust as necessary.
Changing team member locations also helps change things up and gets rid of complacency. A danger for an Agile Team is no longer attempting to make changes and progress because everything is “fine” or “perfect”. If you are hearing these things from your team in Review or Retrospective meetings, perhaps it is time to change desks just to get change happening again.
There may be other personality or non-team type things you wish to address. Instead of bringing that person into an office and talking to them, you could solve things by simply changing desk locations.
Better yet….. If you have a team that has embraces and practices Consultative Decision Making, why not ask the Team where the new person should sit to be most effective!
References:
Scrum Master – Scrum Alliance
Consultative Decision Making -Open Agile Institute
The four stages of team development -Wikipedia.org
Wow! The 3rd and last day of the Scrum Gathering in Seattle was epic! I am tired and thrilled to have participated in such a great day, and such a great conference. Thank you to all who made this happen.
Un-Conference Sessions Using Open Space Technology
This was something that I had some reservations about. What does this mean that we all decide what will happen and how it takes shape? However, this was, by-far, one of the most interesting and engaging parts of the entire conference. Here are the 4 principles of Open Space: (1) The right people show up (2) Whatever happens is the only thing that could (3) It starts when it starts (4) It’s over when it’s over.
There is one law to Open Space: If you are not learning or contributing where you are, find a place when you can learn or contribute.
And there are two roles in Open Space: (1) Bumblebees – these people bounce around to other sessions and add new ideas. (2) Butterflies – these people sit somewhere and look beautiful, and may not attend sessions. I guess that I was neither a bumblebee or butterfly, like most of the participants.
So we were encouraged to come up with topics that we wanted to facilitate and/or learn about and pick a time slot and location. This happened quite naturally – which was added to the marketplace for the participants to choose which sessions they would like to attend and contribute to.
Open Space - one participant adding his session to the wall
My 1st Session – Team Estimation Game by Chris Sims
This is the first time that I had the privilege of seeing Chris in action. He is a dynamic and very effective teacher and facilitator. The game is another method for teams to estimate effort for User Stories (in Scrum) or Value Drivers (in OpenAgile) or whatever you use for your particular Agile method.
He had us form small teams to estimate effort on consuming various types of fruit (which were on cards) including: grapes, orange, durian, pineapple, apple, blueberries, pomegranate, and coconut.
Step One: This was carried out by each person taking turns and doing one of two things: (1) placing a new card on the wall or (2) changing the position of one card. This was pretty easy and allowed us to have conversations on what we meant when we did an action.
Step Two: Then the team had to add numbers (also on cards) as a way to categorize the effort that would be done. Now each person had three options: (1) place a new card number, (2) moving a single card on the wall, or (3) passing which means that you agree with what is currently on the wall.
Chris Sims (on left) showing the Team Estimation Game
My 2nd Session – How to Launch a Team by Roger Brown
Roger showed us a few things to keep in mind when helping to launch an Agile team (usually done by him in a 3 day training on-site).
A ScrumMaster or Coach has certain things to do during the various stages of a team’s development: (1) in Forming, he needs to be directive and tell the team what needs to get done, (2) in Storming, he needs to focus on conflict resolution for the team, (3) in Norming, he needs be a facilitator and observe and then offer ways to improve, and (4) in Performing, he either needs to work on organizational obstacles or move on to another team.
Roger explained how the constant sprint length for a team helps it to get into a rhythm and get data such as the team’s velocity (the speed at which it gets things done). He also offered a great tool for people to use called the Market of Skills which comes from Lyssa Adkin’s book “Coaching Agile Teams”. Other things to use include a team working agreement, team vision, and a definition of done. He said that he likes to spin up 2 or more teams at a time to that they can learn from each other.
<
Notes from Roger Brown - How to Launch a Team
My 3rd Session – Collaborative Work Spaces by Skip Angel
Skip made this session very collaborative and got us to add own challenges and questions to a flip chart page and then get us to share how we would solve each others challenges.
Insights included: share visual stories to help the team see benefits, promote outcomes, tools to use for collaboration. Some tools and useful sites: http://sococo.com, http://onemoreagileblog.com, http://cocoo.com, and http://agileadvice.com !
Skip Angel on Collaborative Work Spaces
Here is the format that he shared for a User Story: As a (type of user) I want (something) so that (value). Enter the things within the parentheses ( ).
Here are the 4 techniques for splitting stories that he shared: (1) Conjunctions / Connectors – words such as if, and, but or even commas. (2) Generic Words – eg. activities which could be broken into sports, dancing, and board games. (3) Acceptance Criteria – which is a list of pass/fail items that if agreed the story is done. (4) Time-line – which are steps of sequence to get something done.
Met Chris Sims
I spoke for a few minutes with Chris. We talked about David Parker who used to work at Berteig Consulting (where I work) and now works at Agile Learning Labs (where Chris works). Chris had nothing but praise for David!
Sharing by Participants on the entire Scrum Gathering
Each person shared something that they like or enjoyed about the conference. I shared three things: (1) the humility of the Certified Scrum Trainers (CST) and the Certified Scrum Coaches (CSC) to share with all of us their knowledge and their ears, (2) the wisdom of everyone at the conference, and (3) the amount of smiles and laughter that was the reality of all of us who attended.
Closing Keynote by Joe Justice and WikiSpeed
Joe gave an epic keynote on his team that built a car that gets 100+ MPG. It was amazing and super inspiring! I don’t even know what to say about it. He and his distributed, collaborative, and highly Agile team of volunteers did incredible things. I hope to buy one of their cars when I done with my current car. It is that good!
Joe Justice showing the WikiSpeed Car
Final Thoughts on the Scrum Gathering in Seattle
So this was my first Scrum Gathering and it was amazing. From the people to the food to sessions to the Open Space to the Certified Scrum Trainers and Certified Scrum Coaches to the people who it made run so well – Fantastic! I hope to attend another Scrum Gathering in the near future. I already plan on attending the one in London, England in October 2011.
Warm regards,
Paul Heidema
So after another day at the Scrum Gathering in Seattle, I am tired! Not just from the sessions, conversations, and the learning but also from waking up in a time zone that is not my own. I live near Toronto which is 3 hours earlier than Seattle. I am slowly getting used to it. Especially that today is a sunny day.
Mastering the Basics of Leadership Storytelling by Steve Denning
Steve Denning showed us how the art of storytelling can uplift and help people to see why a change is needed. He got all of us to do an exercise (1) What’s the problem? (2) What would the world look like if the problem was fixed? (3) Tell the story of the person who doesn’t want the change.
When I did the exercise I though of a client that saw that there was value in using Scrum and Agile but was unable to see the need for organization to adopt them or the urgency to make the change as soon as possible.
Steve also spoke about 3 good ways to get peoples attention: (1) share something unexpected (2) share something relevant to the audience (3) and make it negative. I understand what he is saying but I am more motivated by a positive outlook instead of scaring people by harsh realities. To each his own I guess.
Steve also shared the 7 rules for performing storytelling: (1) maintain eye contact (2) maintain open body stance (3) don’t hide behind notes and podiums (4) use gestures using your whole body (5) dare to pause! (6) practice, practice, practice and (7) be there, be present by planting feet on the ground.
Steve Denning - Leadership Storytelling
I will co-train with Carlton Nettleton
I met again with Carlton Nettleton who is a Certified Scrum Trainer (CST) out of San Diego. I am excited that will be co-training a Certified ScrumMaster (CSM) training seminar sometime in Toronto during the month of August or September. So… keep those dates open! He is very interesting guy and I have no doubt that he is a great teacher and trainer.
I also met Mike Cohn
If you don’t know who Mike Cohn, I recommend searching for him on the net right now! He is a well-known author, trainer and coach in the Agile and Scrum world. We spoke about our experiences and some of our learnings. I also shared how Mishkin Berteig and I have used OpenAgile to help C-level managers and upper managers to be an Agile team so that the teams on the ground see the example by the leadership. He is open and kind man.
Agile Coach Self-Assessment: Where Do You Stand on Competencies by Lyssa Adkins
This is by far my favourite session that I attended in the first 2 days of the 3 day conference. She got all 30 participants to stand and be players in the session. This is what we need more of in conferences that are in the Scrum and Agile world.
Lyssa Adkins - Coaching Competencies
She placed 8 phrases on the ground that were quadrants coming from a centre point that represented parts of an Agile coach. The 8 phrases were: (1) mentoring, (2) technical mastery, (3) transformation mastery, (4) teaching, (5) facilitating, (6) Agile Lean practitioner, (7) business mastery and (8) coaching. We had to do a few things. First, figure which section we were strongest in. Second, choose which section which we wanted to be in. Third, decide which will be our sections to work on (we had to choose 3 in priority) and then choose on section that we would let go.
I also met Vibhu Srinivasan who is one of the newest CSTs (just become one on Sunday). He lives in India and is an extremely nice guy. We were asked to work with one person at the end of the session with Lyssa and then check in with each other to see what progress we made.
Second day was great! Tomorrow we get to be part of the “un-conference” sessions where the participants choose what is important and then prioritize that stuff and work through it together. It should be great!
Warm regards,
Paul Heidema
In an Agile culture, it is considered rude to refer to people as “resources”. People are not fungible – you cannot just take any old developer and plug them into any old project. Skills, personalities, likes, talents, potential all are so dynamic and unique for each individual person. So any management theory (including traditional project management) that treats people as “resources” like oil, gold or computers, is making an unjust simplification at the expense of the people working in the organization.
Yet organizations need to be able to plan where to spend money, and certainly the people working in an organization are often one of the largest costs. From a financial perspective, from a business perspective, it makes sense to somehow treat people costs in the same way as other operational costs… and this often leads to dehumanizing people to the point of treating them like resources.
So how can these legitimate organizational needs for budgeting mesh with the equally legitimate approach of Agile to treating people as unique actors be merged? It is actually quite simple, but the ramifications are deep: treat TEAMS as resources. Teams become the fundamental building blocks of an organization. Teams move from project to project or program to program or operation to operation. There is still a need to support the individuals in an organization, but it is done in the context of teams.
An Agile team is cross-functional, but also constantly learning. Individuals on the team learn skills based on their own interest, but also based on the needs of the team for redundancy, parallelism, and expansion of capacity to take on new, more challenging work. Cross-functional teams can more easily (and more sanely) be compared for their value to the organization by looking at things such as their ability to produce finished product/services, their flexibility in serving the needs of the organization, and the quality/consistency of the work they produce. Teams can compete in a healthy way by striving for excellence in delivering value to the organization, whereas often competition between individuals can be quite unhealthy.
From a budget perspective, teams are easy to manage: each team has a fully loaded cost based on salaries, space, equipment, etc. The cost is (or can be) relatively stable or grow predictably, and can still be handled operationally. As well, unlike individuals, it is much easier to treat a whole team as a fungible unit: you feed work to teams based on their availability rather than based on a detailed analysis of their skills/capacities/allocations.
In Agile organizations, teams are resources, people are not.