Team Members’ Profile Game

Source: Wikipedia

• Let everyone facing uncertainty
• Putting each one in someone other’s shoes.
  Actually, you are called to understand, feel, make it yours and finally explain, something that someone else thinks and feels.
• Communicate face-to-face with another attendee (team member)
• Practice the art of listening

The Agile Team: a tribe or a theatral troupe?

http://broadwayhour.blogspot.com

Belonging to a theatral troupe, actors work for a long period each one near the other, they are invited, sometimes obliged by the situations, to find the most effective working behaviors, sinergies and approaches in order to let the show hits the ground.
Any actor should have a talent, have studied and practiced a lot, know very well her part in the show. But this is not enough because she is called to adapt, adjust and tailor his artistic behaviour to the existing boundaries: the other actors with their parts, behaviors, skills and approaches.
Furthermore, the actors must limit theirselves and their behaviors within spaces (the stage, the scenes), timings (acts, show).
Finally, they use as well iterations when make the rehearsals.

http://humansarefree.com/2011/06/ten-commandments-of-native-american.html

Members that belong to a tribe, accept to share not only the usual activities such as hunting, providing for the maintenance of the tribe or, furthermore, fighting. They want to share also personal experiences, spaces, feelings, emotions, accepting rules and participating in rituals and ceremonies.

 

Hence, an agile team member, like an actor, should know the “theory” and should have practiced a lot. Every activity he does is limited in terms of time (iterations), space (the workplace). He should be able to communicate well enough to collaborate with the teammates and be effective working in a group. He will take advantage of the feedback coming from the iterations and discovering and learning form the experience.

An agile team member, like a member of a tribe, should accept and follows some rules, to find the right balance between his expectations and the ones of the group. He should trust the other members at least until his trust is betrayed and in my experience this does not happen too frequently in an agile team.

Actually the parallelism with rugby is somehow perfect. Scrum in rugby, is the way the members as a team operate to conquer the ball against the counterparts.

SCRUM Simulation, the Resort Brochure Collaborative Game

On thursday and friday 24th and 25th, I gave a SCRUM training course for the European School of Project Management in Turin.

One of the most important thing, in my opinion, when in a training course you talk about a project team and its ability to collaborate, self-organize, learn from the experience, and communicate effectively (that’s SCRUM actually) is that you should find a way to let the attendees, work as a team, in order to test the knowledge just learnt, simulating one or more iteration sprints.

I know some collaborative games, such as SCRUM lego city game, that can be used to simulate SCRUM and iterations, but I prefer the resort brochure game or product box collaborative games because they are easier.

On friday, during the last hour of the course, we played the resort brochure game.

Let’s see what it is and what are the rules of the game.

Create teams of 5/9 people.

The goal is to create a brochure for a brand new resort. The brochure should contain the right layout, messages, images  in order to promote the activities and the strengths of the resort.

First of all, the team shall create the user stories in terms of how and what the resort should be (e.g. As a manager, I want meeting rooms, completely accessoried, where I can arrange business meetings, so that I can arrange projects’ kick-off or As a husband, or  I would a resort with a spa inside, so that I can celebrate my wedding anniversary).
During this phase, the team should also choose a product owner which is in charge of prioritize the user stories, write them down in index cards and put them into the task board in the TODO or Backlog Items column.

This period should last no more than five minutes.

Then, the team is ready to start.
Arrange 2/3 iterations of 3 days (5 minutes each day, a total of 15 minutes for each iteration).
The team starts the first iteration conducting the sprint planning meeting, during which the members decide about what stories they commit to finish and asking for some more details to the product owner.

Every day starts with the Daily Meeting, the team members say about what they did the day before moving the index cards through the taskboard, what they are going to do during the current day and finally if they have any road-block; immediately after, they begin to use scissors, rulers, glues, markers, paper to create the product: the resort brochure.

When an iteration finishes, the team shows the results to the stakeholders in order to demonstrate how is going and to elicit any feedback in order to adjust the product.

Actually, what the attendees of my course did yesterday, was amazing. They unfortunately hadn’t have three iterations because of time, but only one and what they produced was incredible.

I saw a great collaboration between them, one member of the team was actually a graphic and she facilitated the birth of the concept and the layout definition; the team decided what kind of images to choose and how to arrange them.
Another attendee was in charge to propose some claims and inspiring message to introduce into the brochure. The other ones helped the graphic cutting images from magazines, drawing, writing, glueing, composing the brochure.

I think that this games worked so well because most of the attendees were women. Actually the men helped but actually, they were not so confident with magazines, scissors and rulers.

With courses where the most part of the attendees are men, I use to play the Product Vision Box (Managing Agile Projects, Sanjiv Augustine). The scope of this game is similar to the previous one in terms of materials to use, but the team must create the box of a product. The team shall decide about which product they want to sell and after they decide about the box layout.

Facilitating the process of learning and growth of an agile team

Every time I teach in a course, whatever the content, even if the organizer tried to arrange the classes in a balanced way in terms of experience level of the attendees, it happens that someone knows less than the others regarding the area I’m going to talk about.

In these cases, I try to keep aligned the class starting from the basic concepts, avoiding to be excessively detailed and trying not to annoy the experts. Then, when I switch to the advanced topics, I make a great use of metaphores: it helps to catch the gist using past experience, idioms or whatever could sustain the interest of the whole class.

It happens, though, that the experts patiently wait for some more details and once supplied, the novices start to shake their heads, looking at me somehow “lost in transactions”.

This happens because it is usual that, when we are called to learn something new, we should pass through three different stages:

1. Following
2. Detaching
3. Fluent

Alistair Cockburn explains this theory very well here. That theory, actually, is somehow inherited from the Shu-ha-ri martial art japanese concept, which describes the stages of learning to mastery.

ShuHaRi - Wikipedia

When we are learning something new, something not easy, we are completely dedicated to understand the topic, circumscribe it and finally derive a method that could help us facing that new knowledge.

Any additional information, alternative, tip or trick is not well accepted during this phase, most of the time is discarded as “waste“, because during this step we only want to learn the easiest and most effective approach to “survive”: other data is entropy.

At least for a period of time that can vary from one weak to 6/8 weeks (depending on the complexity, etc.), we are called to practice the new knowledge, inspecting and adapting our approach in order to verify what we learned. It’s during this phase that we feel the  necessity to find other ways to solve the problem, exploring new paths.

Mary Poppendieck - In theory there's no difference between theory and practice, in practice there is.

This is the exact moment when we enter the second stage called detaching (or leaving).

We are no more satisfied of what we have learned so far, probably we found some flaws, we want alternatives, walkarounds, more detail regarding the problem and what causes it. That’s the moment to come back to books or teachers learning something new.

Again it’s a matter of time and dedication. Lot of water has to pass under the bridge, we just need to practice the new knowledge, like when we learn to swim. In that occasion we repeated the same movements many times, again, again and over again, letting that “knowledge” passes from the conscious to the unconscious mind, also called “muscle-memory“, that digests that knowledge and makes it available, automatically.

Papua New Guinea proverb: Knowledge is only a rumor until it’s in the muscle

Finally, the water passed under the bridge and we don’t strive anymore to use the knwoledge: it is part of us. It happens and that’s enough.

As it happens to trainers to have course’s attendees with different level of knowledge, it happens to team leaders or coaches, to have teams that comprise both juniors and seniors members.

In this case the XP practice of pair-programming help-us.

Pairing helps juniors when they are navigators as well as drivers.

As “navigators” they have the possibility to see, ask and verify new approaches, techniques, tools and as “dirvers” they can practice what they just learned, being corrected immediately in case of errors. Both situations take advantage of one of the most important values of agile discipline: the short-feedback-cycle.

And what if we don’t have aboard any senior team member? In this case we as Scrum Master, Agile Coach or technical leaders, are called to get our hands dirty, pairing with the juniors and bringing some new fresh air by teaching new things, concepts, approaches.

This could be the moment when we cross over the Tuckman’s theory.

Tuckman's Theory: Forming, Storming, Norming, Performing

1. Forming
2. Storming
3. Norming
4. Performing

During the first stage (forming), the team listen to what you’re saying trying to accomodate this new knowledge with the one they already have: they don’t want to argue, they only want to learn and understand how to apply new knowledge.

During the storming phase, instead, different ideas and perspectives grow, they don’t want to change or they fear changes: but most of the times it is only a matter of listen to their doubts, assuring about the goodness of the theory and finally practicing, a lot.

This for sure will happen the first time a team embraces SCRUM: the first iterations aren’t so easy and the team will try to force to change the rules of the game, trying to cut some practices or changing some behaviors.

In these case is very usefull to put in practice what Jeff Sutherland called the Shock Therapy that can be summarized as follows:

1. Train the team
2. Set iteration length to 1/2 weeks, in order to have a short feedback between what the team does and what are the results
3. Set Definition of Done
4. Large use of information radiators
5. Respect any SCRUM meeting
6. Do not change anything before three months

Furthermore, he used to say to the team the first time it entered the workplace, that it is like when a karateka enters in a new Dojo. Above the entrance there’s a poster saying

“Forget what you know about karate,
forget your way of doing that,
this is my dojo,
you all are asked to do it my way“

Acting as a zipper: here is the Product Owner.

The product owner (PO) in SCRUM, is one of the most crucial figure of the stakeholders community formed around a SCRUM project.

His role is to behave as an interface primarily between the team and the management, adapting the behaviour, the ledership style, the way he communicates time at a time, in relation to which he is confronting with.
He should master the communication and negotiation techniques, he should also know how to manage politics and take advantage from it.

On the other side, the Scrum Master is mainly a coach, a mentor, somehow it could be tought as a wise father in charge to give the team support and guidance. He must have strong communication skill as well and he should be an active listener and  a servant leader, protecting the team and creating a favorable workplace.

The PO is even more important when the client organization is not part of the one that is creating the product and, moreover, if it is not familiar with the agile practices and concepts.

It happens in these cases that the client organization is also particulary fond of the traditional way of conducting and controlling projects and it doesn’t want to change the way it works.
The PO, hence, must actively keep the client informed by sending at a regular basis, fresh information about project’s progress, using the same “project language” of the customer: gantt, Earned Value analysis, etc.

It is obviously auspicable, looking from the agile perspective, that the client participates at least to the Demo/Reiew meeting that the team holds every end-iteration, showing the actual progress in term of what was developed so far and that is ready to go live.

SCRUM and XP as well, indeed, prescribe the practice of “customer-on-site” that means the client is strongly involved in and engaged with the team, in the same workplace, during the entire lifecycle of the project. This could be challenging, but it brings lot of advantages that are mostly related with the fact of establishing short lines of communication that drives to short feedback between the team and the customer, avoiding misunderstandings and shortening the time necessary for decision making.

One last advantage is that the customer itself is able to see how the project is progressing, looking at the Task Board, the sprint and release Burndown Chart, the Impediment Log.

But, as we assumed initially for the sake of this example, our customer doesn’t want to be so much involved and engaged, he is not interested in any agile practices or knowledge, he only wants the product he asked for within the time, cost and quality decided and, finally, he wants to receive punctual updates about project’s progress

In short,a real nightmare for a pure agilist :\
Someone said me that in these case s/he refuses the job.

My opinion is that even in these cases, we should be adaptive and responsive to the situation, by adapting our style to the customer’s one, using the Product Owner (internal in this case) as a zipper, a tradeoff figure, an active interface between the traditional project management style of the customer and the agile approach of the internal team.

Let’s assume we choose the second case.
First of all, I suggest to the PO to try continuosly to engage as much as possibile the customer.

The first duty that the PO must assolve, is to gather the requirements and write the user stories. During the meetings he will held with the customer for that, he should find the way to give some “agile” pills to the patient: talking about the ceremonies (planning, daily, demo and retrospective meetings), the artifacts (product, release and sprint backlog, burndown charts, impediment backlog), the roles and, why not, the rules of SCRUM.

Another important thing the PO should do during the gathering requirements meetings, is to collect all the functionalities the customer wants, initially without a great extent of detail and to ask the customer to prioritize them, understanding the real business value the customer assignes (see this previous post).

The most important requirements, those with an high prority, must be “decomposed” into user stories, the other less important requirements will be put into the product backlog as they are, without exploring them too much in this first moment.
This because those requirement will be analyzed only after the first versions of the product are available, giving the customer the opportunity to change his mind, introducing something else or, even, cancelling such requirements because he already achieved the ROI.

Then, the PO, should try to bring the customer at the “war room“, the place where the team is working, to let him to be part of the “flow” even if for few moments.

In this occasion the Scrum Master must be present as well, behaving as a Cicerone explaining how and why the workplace is arranged that way, how the data reported on the information radiators can be interpreted, how the team works and why such a high level of involvement is so important.

Another important step of persuasion the PO should try, is to insist to have a customer representation present during the demo meeting, inviting him or asking to delegate someone else, to participate the demo/review meeting, to see how the product is evolving.

In these situations, indeed, I prefer to set short iteration lenght, because the fact that the client is not so involved and passionate, increases the risks and the probability of misunderstanding. Having the possibility to release frequently, on production, small chunks of working software, helps to prevent it.

The PO, then, must interact proactively with the team acting as the customer, giving opinions, guidance and solving problems about what and how the product should be and work.

And finally, the last great effort the PO has to do, is to keep informed the customer at a regular basis with the progress status of the product, by transforming the information spread around the several information radiators, into the documents the customer really wants: the WBS, the Gantt Chart, the Earned Value Analysis.

Creating the WBS is somehow simple because it is mainly a hierarchical structure of the work that must be done, dividing it into nodes, sub-nodes and leaves that must be arranged by deliverables. The term deliverable means a piece of finished functioning work, that can be released to the customer in order to be evaluated and eventually put on production. This, for an agilist, sounds good because the equation could be deliverable = iteration or in the worst case deliverable = release.

The WBS hence could be arranged by reporting the releases, the iterations for each release and finally which stories the team is going to implement for each iteration.

Actually, this is only the first step the PO should do to keep aligned a recalcitrant customer with the progress of an agile project, by creating traditional project management documentation. The other steps are create a Gantt chart from a SCRUM Task Board and produce a status and forecast report about the perfomance of the project, by relating the burndown chart data, the velocity, the iterations planned into a fantastic Earned Value Analysis.

I’ll try to cover also these two last point (the tough ones actually) in some future posts. Keep in touch!

The SWOT: an innovative tool for agile retrospective

Yes, of course I’m joking, the SWOT analysis isn’t an innovative tool, but have you ever use it for analysing how an iteration has gone?

Hi there, holidays are over and a new working year is ready to start!
During my vacations I read a lot about agile retrospectives and it was an opportunity to compare the techniques and the tools mentioned in those books, with the ones I use in my everyday working life.

What actually I did not found is one of my preferred tool: the SWOT analysis.
That tecnique is so versatile that can be adapted easily. It was born to be used mostly for conducting marketing activities to devise new products.
On the other side, that of the traditional project management approach, it was applied to the projects in order to conduct the risk identification phase.

Actually, I use that technique at least in two other occasions.

Firstly, when I want to stimulate and accompanying the growth process mine and of my colleagues and team members. I help them to identify, related to their job and daily working activities, what are their strenghts and weaknesses in order to understand which opportunities could be developed and to what weaknesses they are exposed to.
Secondly, it is a fantastic tool to conduct a retrospective meeting. How? Let’s go!

As the major part of you already know, an agile retroscpective meeting is a meeting that usually lasts 4 hours, which is held at the end of a sprint (iteration), just immediately after the team has shown what it was developed (demo meeting).

The scope of this meeting is to reflect about what was good and what was bad about the last iteration. Considering the necessity to help people to actively participate and freely express opinions, ideas and any doubts, it’s better (read as mandatory) if that meeting is opened only to the the team, the scrum master, and the product owner (but only as a spectator).

Once the environment is ok and the meeting is open, distribute to the participants the SWOT matrix template and ask to each to address their thoughts on the iteration just concluded.
The focus is on the tools and techniques used, the approaches and behaviours kept by the people involved, the things happened during the iteration.
It is mandatory to absolutely avoid any direct reference to collegues, rather indicate the behaviour that should be rewarded or penalized, never cite an individual.
Remember that it is not a matter of finding the guilty, it’s a matter of improve performance and why not, to work better with sustainable paces.

Compile

The first quadrant contains the strenghts: which attitudes, behaviours, approaches were good. What, in the end, shall be reiterated to actually continuing to bring real worth to the project.

The second quadrant is a container of weaknesses (please do not confuse it as a garbage bin, there’s much to learn from our weaknesses): think of what has gone in the wrong way and analyze what is missing and where the problems were.
Think about the bad effect that was caused by the problem and try to conduct an analysis in order to climb to the root reason.

Now it’s time to concentrate on what could be exploited and what should be avoided: respectively the opportunities and threats quadrants.
The opportunities quadrant should comprise a list of “good things/objectives” the team/project/sprint could reach in case of investing in improving the strengths or bridging the weaknesses above reported. If possible connect each opportunities or threats to the relative strenght or weakness.

On the contrary the threats quadrant is reserved to the consequences that could arise in case no improvement is put in place.

Arrange

When every team member has finished to compile the “SWOT”, it’s time for each of them to write on a white-board, flip-charts or sticky notes both the strengths (good things) and weaknesses (bad things) giving insights regarding the opportunities and threats that they can bring aboard.

When finished, the agile retrospective leader (role that should be assigned in rotation to every team member), tries to identify which items are duplicate, eliminate them and  the remaining are grouped, clustering them under a category, a word, a statement that clearly explains them.
Now you have a well arranged situation of what has been the iteration just finished, in terms of good and bad things: solicit the team to devise and propose activities that aim to solve problems and enhance the performance according to what above reported.

Vote

And, finally, it’s time to vote: do you know DotVoting?
Simply assign a predefined number of votes to each team member that he can distribute on the activities.
Everyone can assign one vote for each desired item or assign all the dots/votes to one item, if they feel that is an important one.

Arrange the result as a bar graph (do you remember pareto and the 80/20 rule?) and pick the most voted activities, those must be executed during the course of the next sprint.

Final Considerations

• Do not put into the pipeline too many activities for the next iteration; most of the time it is better to process one at a time.
• Try to focus on the strenghts instead of weaknesses.
  Try to maximize the benefits coming from what the people can do better: their talents and qualities.
  It is more difficult to work on weaknesses.
  Obviously, if the weakness has an heavy and bad impact on the team/project/sprint, do not hesitate to deal with it.
• Everyone during the meeting should actively participate: your responsibility as a Scrum Master is to go along with the retrospective leader and stimulate who is not actively participating or try to contain who tends to speak to much or has a coercitive approach.
• Keep in mind these three words: APDC, CPI, Kaizen. They teach us to continue to improve the process, even a small adjustment can lead to great improvements.

Prioritizing User Stories

One of the most important survey results conducted by an important international organization, states that 64% of the functionalities included in software products are never or almost never used!
How come?!?
One way to avoid such a waste of resources, is to assign priorities to the user stories and to develop them starting from the highest.

 This post wants to address that 64% of features to be developed, which are never used by the final users once the product is deployed on production. After all, avoiding those features isn’t a way to reduce costs and time necessary to go live?

Let’s see how SCRUM faces to this issue.
As you probably know, the SCRUM framework provides three different roles: the team, the scrum master (SM) and the product owner (PO) (see URL). All of them are important. Maybe the team can be considered the most important, but for sure, SCRUM cannot work if any of those is missing.

This post is dedicated to the important role of the Product Owner and to one of its duties: prioritizing the features!

Once the gathering requirements phase is finished, the product owner should have in her hands a list of index/note cards in which are written the user stories.

The process of prioritization, must be conducted in order to:

1. Maximize and accelerate the ROI
2. Reduce risks

In order to maximize te ROI, the PO must have a clear understanding of what the customer wants in terms of: objectives, necessities, opportunities to reach, in one word, she must understand what is the actual Customer Business Value to gather.

Reducing risks, on the other hand, is primarily a matter of:

• Remove any impediments
• Give answers and explanations to any doubts or open points
• Deepen, if necessary, user stories that are not clear
• Execute as soon as possible any critical project activities

We can consider critical, an activity that will use a new technology not yet known to the team.
Or, furthermore, an activity that is one of the most important of the entire product, over which there are lot of expectations from the project stakeholders.

For the first case mentioned (new technology) is important to work on that feature as soon as possibile in order to “understand” the new technology and how to work with it. This will allow the team to capitalize the knowledge just acquired and will lower the risks.

Facing the second case (hot feature), it is again a matter of work quickly on it and to fast deliver it in order to receive, even here as soon as possible, feedback from the stakeholders.

Thus, it’s only a matter of assigning the right priorities, isnt’ it?! Yes but, how?

Actually, there are many methods available to achieve that goal, but the one I want to explore today, is the one that takes care of the customer business value and the risks associated to each feature, assigning to them an index (from 1 to 10 for example) in order to draw a point in a x/y graph.

This method is also mentioned in one of Mike Cohn’s books (Agile Estimating and Planning) that I strongly suggest to read.

So, let’s use Excel.

Create a new worksheet containing three columns: User story ID (or title), Business Value Index, Risk Index.

List all the user stories and for each one first assign a business value index: 1 for the lowest and 10 for the highest.
Higher values should be assigned to each activity that directly aims to one or more of the objectives to be achieved.
Lower values should be assigned to the activities not so important in achieving the goals like ancillary activites, maintenance or administrative activities, reports, etc.

Once a business value index is assigned for each feature, is time to provide risk indexes.
Higher values should be assigned to critical features like those that uses new technologies, those not well described or well understood, those that have  many interactions with external systems, those that will serve different typology of users and so on.
Lower values should be assigned to the remaining acitivities.

Now it’s time to create a graph, having excel plotting the points.

Now, compare the graph you obtained with the reference matrix above reported.

Well, it is time to start working and remember: the features never or almost never used, are the ones having a lower business value assigned; so, do them at the end and, furthermore, try to avoid those with an high risk associated!

Playing Collaborative Games

It often happens that I teach in IT and project management courses.
What I’ve experienced is that one the of hardest thing to do in those situations, is to maintain high the level of interest and concentration of the attendees, allowing them to gather the greatest benefit from the course itself.
Actually there’s a secret…let them play!

On january I was in Scotland to attend to the SCRUM Master Certification Training Course.

In that occasion Simon, the trainer, organized some interesting games where the attendees, me included, were physically involved.
As usualy happens we were initially reluctant, but once the ice was broken the involvement of each one was really high, as well as the enthusiasm for the results.

Another occasion during which the collaborative games were used as training tools, was during the Italian Agile Coach Camp in Umbria. Unfortunately, I did not participate to those games because contemporarily there were other interesting tracks and I could not avoid to participate; it was really a pitty!

But, lucky me, we had retrospectives about those game sessions and I had the possibility to understand the actual worth of doing those games.

Both the two occasions were triggers for me. They helped me to deeply understand what such a powerful tool the collaborative games is!

Why?!?

1. First of all, they are games. People love to play games, even more if their company pays for it!
2. Second, players have still to pay for playing: you pay, leaving your comfortable zone and putting yourself into a new situation.
3. Third, the attendee is physically, not only mentally, involved. This helps the process of learning and facilitates the brain to store and consequently to remember and recover it.
4. Fourth, is a stimulus for the attendee to immediately activate the passive knowledge s/he has just learnt listening to the trainer.
5. Fifth, a game establishes a cheerful environment and creates a team building effect.

In other words, playing games help us to better understand because of the short feedback cycle (it sounds familiar, doesn’t it?).

Playing collaborative games is a quite sure way to energize the attendees, having them concentrated during the entire course. Which games I used to play in my courses?

A must game is the penny game, but also the specifiers and doers game using a set of role cards to introduce biases or, again, the alphabet games to consolidate what was learnt and the planning poker game.

Furthermore, I also use information radiators such as whiteboards, flipcharts, note cards stuck on the walls,  a task kanban board that shows the progress of each topic of the course, which helps the attendees to see progresses.

Agile Coach Camp Outcomes

The past week-end I attended the Agile Coach Camp un-conference, that took place in Umbria in a lovely venue called La Casella.

The main objective of that un-conference was to aggregate people interested in agile project management and coaching practices. As described in the event home-page:

Two days of highly collaborative, (mostly) self-organized event with Agile coach dojo and OpenSpace for everyone involved in coaching,training, mentoring and leading Agile Organizations, Teams and Individuals.
ScrumMasters, team leads, guerilla Change Agents, ProductOwners, managers, other roles are all welcome. Diversity makes us smarter!

What a fantastic experience it has been!

I’ve known special people: people whose only objective was to collaborate and share ideas, knowledge, experience and thoughts.

People who know that in these cases the real result of the sum of two ideas is more than the algebrical result.

People that consider more important the growth of the community that its.

Passionate people who love what is doing and ready to share its passion with you.

Did I already said that it has been a great experience?