Charley says ..
Make commitments to the team in the
daily stand-up.
If you're in the UK, do you remember '
Charley says'? If you're not in the UK, the '
Charley says' series of public information films were animated cartoons featuring a little boy and his wise cat, Charley. Made in the 70s, the moral of each story, e.g. about the dangers of matches, was miaowed by the cat and translated into English by the little boy.
Gus bought the '
Charley says' postcard, which I stuck to the side of our
planning board, to remind everybody in our team to say what they
completed yesterday, what they'll
complete today and what obstacles are in their way.
So, basically, say what you'll do and do what you'll say. And hold others accountable to their commitments.
Tags:
daily stand-up
Links to this post
Planning board and user story cards
Card colours:- White for business value user stories from our Onsite Customer.
- Blue for technical debt and engineering work.
- Pink for defects.
- Yellow for QA specific engineering work, e.g. setting up test boxes, configuring cruisecontrol, maven2 build and selenium for cross-browser testing (generally we don't get many of these cards because QA is implicit in everything we do).
(The single green card was for one-off special work that we needed a different colour card for. We don't need this colour card anymore.)
The colour stickers on the cards correspond to the columns on the planning board, which are also colour coded. Some of the cards have lots of stickers on them because we develop the user stories by
vertically slicing them. Each slice starts 'In Development' (red column), and moves through a 'UI Review' (black column) and a 'QA Review' (blue column) before arriving at a 'Customer Preview (orange column). Here we get valuable feedback from our Customer before returning the card to 'In development' to start the next slice.
Here's our story card template:
samplestorycard
Originally uploaded by sjb140470.Tags:
agile,
planning board
Links to this post
Presentation introducing agile thinking and Scrum
Here's a presentation I gave yesterday at my current client that introduces
agile thinking and Scrum.
Tags:
agile,
scrum
Links to this post
Command and control? Er, I don't think so
I've had this post kicking around in various pieces for a while. I don't know if I've said all I want to say, but it's late and I'm tired so I'm putting it out there ...
Command and control elicits compliance to enforced processes through management by policy. Focusing on process fixates management on the means rather than the result. Emphasis is placed on building hierarchies, formalising roles, and people are viewed as resources. All this amounts to bureaucracy and adds no value. Hierarchies introduce protracted decision-making. Decisions made up the hierarchy typically don't involve the people who will be tasked with fulfilling the decisions. And consequently, the support from these people for the decisions is absent. These decisions aren't easily reversed. All this nonsense doesn't exactly set the project up for success. I can't think of a better way to demotivate people and reduce productivity.
Work that is fun and people-oriented is the most powerful motivator I have encountered. So why not empower people working at the coal-face? Provide facilitation and let them self-organise and decide how they will get things done. Decisions made at the coal-face can be made quickly, allowing them to be delayed until the latest responsible moment when more information is available. When a decision doesn't work out, it can be reversed quickly and an alternative decision taken based on the feedback.
Encourage people to communicate honestly and share information openly by making everything immediately public and visible. Through frequent self-inspection, encourage learning and continuous improvement through adaptation. Don't use a project manager to drive the project using a project plan. Instead, have the customer steer the project through continuous collaboration and regular feedback. Have everyone focus on productivity and delivering results by making public commitments, agreed by consensus, to deliver agreed value to the business.
Links to this post
Relating to the dangers when adopting Agile
After 6 months I'm still really enjoying my curent contract. However, I can relate to
Siddharta Govindaraj's
5 dangers when adopting Agile. I'm contracted by a department in a large organisation and I'm working on a project that is part of a much larger program of work. Like any work, it has its ups and downs. The ups generally relate to the project, the people I'm working with and not having to compromise on our team's use of Extreme Programming, Scrum and Lean thinking. The downs are moments of annoying frustration when we encounter the wider program and its organisation, bureaucracy and dysfunction.
The department wants the benefits of Agile, so I ask myself why has the program been organised as the antithesis of Agile? It's partly historical but also I think it's because they're
unfamiliar with Agile. Most people involved in the program but not our project see the practices we employ, and they understand some of them, but they're not
seeing the
value system that we've built nor do they fully comprehend the
principles that guide our actions.
For me, Agile is
all or nothing. Find the right people. Live by the values. Be guided by the principles. Practice all the practices. Gather feedback often and then adapt. And we have that in our team. We're self-organising and empowered; we make commitments and then deliver; we are colocated with our customers encamped on the edge of our bullpen (they're not in it because we do not have the room to expand the bullpen area). We've achieved these things because we're operating in a vacuum and our work to date has been ring-fenced without dependencies on the rest of the program or the organisation. The program's adoption of Agile is effectively an
incomplete implementation. We're an Agile development team embedded within in a program office driven by
top-down thinking.
Our team's culture is founded on open and honest communication, collaboration, visibility and accountability. We get work done. We deliver value to our customer, frequently and regularly. The corporate culture is about process. I see bureaucracy and a lot waste. And often mediocre performance is the norm, even worse it's accepted. Our team's situation is likely to change soon as the focus of our work shifts and expands. I'm looking forward to this happening because it'll take us out of our vacuum. But I worry about two things. First, dependencies on other teams being introduced. As my friend and co-worker
Gus Power says,
the agility of a project is generally inversely proportional to the number of people involved who are external to the team. Second, the inevitable clash of the two cultures and working styles. I'm hoping we will not be asked or forced to change our value system and working practices. Why would you want to change something that is clearly working so that it can work with something that clearly isn't working? Can our agility bring about a wider
culture change, at least in the program office? Maybe. It depends on the willingness of people to move beyond the comfort zone provided by a command and control environment.
Fortunately, the organisation doesn't see Agile as a
silver bullet. It recognises that there are other factors that contribute to success. Looking to the future, I'd like to see more people, especially executive management, actively learning about Agile to attain a deeper understanding. I can't see the wider organisation changing (for a long time) but I would like to see visible and tangible steps taken to bring about organisational and cultural change throughout the program office so that a full implementation of Agile can be achieved. This would prevent any
schismogenesis between the Agile team and the surrounding program office.
Tags:
agile
Links to this post
Agile governance games
I recently attended
Jason Gorman's session on
Agile Governance, which explores the mathematical dimensions of planning techniques. I enjoyed it immensely because it's a particularly interesting topic and Jason's clear command of the subject matter coupled with his engaging presentation style provokes thought and debate. I invited Jason to come in and run the games with the team I'm working with. It was lot's of fun.
Read Jason's very interesting
comments on the event.
agilegovernance-thundercharts
Originally uploaded by sjb140470.
agilegovernance-jasontalksprobabilities
Originally uploaded by sjb140470.Tags:
agile planning
Links to this post
Agile pick-and-mix
I don't like the pick-and-mix approach to agile practices (I'm talking about Extreme Programming and Scrum), especially in the name of pragmatism. What about the
values and
principles? They're kinda key to Agile. For me it's all or nothing. Fundamentally there needs to be an inculcation of
values and
principles into the organisation's culture and people. And all the practices need to be employed (preferably in one go) because they produce better results when they're used together. If you only select some practices, and ignore the
value system and
principles, then you're not giving Agile a fair chance of success. I've heard too many organisations say "we tried Agile and it didn't work". What they've actually done is bought a book, read it, and then selected some of the practices and expected the developers to just use them. No wonder Agile didn't work.
This half-arsed and gutless approach to agile methods doesn't do anyone any favours. It doesn't really help the organisation trying to adopt agile methods and it certainly doesn't do the Agile movement any good either.
If you're contemplating Agile, do it all and get an experienced coach to help you. If you can't or don't want to do it all, do me a favour and don't do any of it.
As for certification ... please, No!
Tags:
agile
Links to this post
I read Patrick Lencioni's book,
The Five Dysfunctions of a Team, today. The whole thing. It's 224 pages but written in a big font. I started reading it on the train into work and I finished it on the train home. And it was difficult to not pick it up during work.
Patrick writes in an engaging tone that reels you in. He tells the story of Kathryn, a CEO hired into a start-up company, which after 2 years is in steady decline, to turn around a dysfunctional executive management team and ultimately the fortunes of the company.
Here are 2 conclusions Patrick draws from the story that resonate with me:
Teamwork ultimately comes down to practicing a small set of principles over a long period of time. Success is not a matter of mastering subtle, sophisticated theory, but rather of embracing common sense with uncommon levels of discipline and persistence.Teams succeed because they are human. By acknowledging the imperfections of their humaity, members of teams overcome the natural tendencies that make trust, conflict, commitment, accountability, and a focus on results so elusive.
Links to this post
Retrospectives: Action begets action
We've been doing a
heartbeat retrospective at the end of every
1-week iteration to reflect on our team, our methods and our interactions. Our
iteration review concludes at 5pm on a
Tuesday and the last thing we do is the retrospective. They've been taking around 30 minutes and have basically been a facilitated group discussion focusing on what we did well and areas for improvement. From the retrospective, we took no more than 2 action items (sometimes
user stories), targetting a specific thing to improve on, into the next iteration. This perhaps sounds good enough, and we do continue to improve, but I don't believe we've been getting the most out of our retrospectives. What's worried me for some time is how frustrating these retrospectives have become for everyone involved.
The iteration before last was a tough one and the retrospective was particularly frustrating for everyone. The next day, following our iteration planning game, I wanted to revisit the frustrations with the team so I went out, got some chocolates and fruit, and when I got back I
called a timeout. We had a good discussion, which turned naturally into the retrospective for the previous iteration. It was a very reflective and productive session.
We decided on 3 changes to our
heartbeat retrospectives.
First, everyone said they could offer more in the retrospective if they had time to 'decompress' after the iteration and sleep on it. Since our iteration planning games were taking 1 hour or less, we decided to hold the retrospective immediately before the planning game for the next iteration. It's important to conduct the retrospective before the planning game so that you can take new knowledge and any actions (or
user stories) into the next iteration. Giving up 1 hour of the next iteration to conduct a better retrospective for the previous iteration was deemed worthwhile.
Second, as the saying goes 'action begets action'. We decided to extend the retrospective to 1 hour so that we could include activities that would spice things up, get people moving about and inject some energy into the experience.
Third, we decided to take only one thing, the most important thing, into the next iteration that would help us improve in a chosen area. We wanted a single focus and we felt that other important things would recur and probably surface in the next retrospective, just 1 week away.
Today, we completed our first new-retrospective before our planning game. It was fun, vibrant, focused, very reflective, and we came out of it with a single objective, which we took into the next iteration as a user story. The nucleus of the new format essentially follows
James Shore's retrospective and I've added a check-in to open the session and a
ROTI assessment to close it. Here's the agenda:
1. Prime DirectiveNorm Kerth says:
The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive. Set the stage by reading the
Prime Directive out loud and then, in turn, ask each person to say whether they can agree to it.
2. Open - Check-In (5 min)Get everyone to check-in to the retrospective by asking each person to say in one or two words how they feel about the iteration. This way everyone says something from the start and it helps people to continue to be vocal and involved throughout the retrospective.
3. Brainstorming (20 min)Paraphrasing
James Shore:
Ask the team to think back to the iteration and brainstorm the events that were enjoyable, frustrating, and puzzling, and consider what you'd like more of, less of, and to remain the same. Write each idea on a separate post-it note and don't worry about duplication.
retrospective-brainstorm2
Originally uploaded by sjb140470.4. Dumb Mapping (15 min)This is a variation on affinity mapping but without speech. It's a lot fun devising various ways to communicate with people without talking. Semaphores. Gesticulation. Hand signals. Eyebrow maneuvers. The goal is to group related post-it notes, assign each group a name, and then
dot-vote to identify the most important group to improve on in the next iteration.
retrospective-dotvote
Originally uploaded by sjb140470.5. Retrospective objective (15 min)Given the most important group, ask the team to brainstorm 6 ideas for improving it. The team should select one course of action, by
consensus, and take it into the next iteration as an action (on the team's action list) or as a user story. In our retrospective, our most important group was 'build'. Our various builds (continuous integration, nightly, site, performance tests, uat) were vying for processor time and people felt that the plethora of
cruisecontrol projects were complicating the overall build schedule. We took a user story into the next iteration to rationalise the
cruisecontrol projects.
retrospective-objectiveideas
Originally uploaded by sjb140470.6. Close - ROTI (5 min) Our frustration levels sparked this change to our retrospectives, so I like to close the session with each person, in turn, stating a number from 0 to 4 that reflects the return on their time invested. 0 indicates a low return. 2 breaks even. And 4 indicates a high return. The numbers are recorded on a histogram. I ask those people who rated the retrospective 2 or higher to say what benefits they received. Here's our histogram:
retrospective-roti
Originally uploaded by sjb140470.Tags:
extreme programming,
retrospective
Links to this post
Amusement at work
Sometimes it's amusing working where I'm working. People in the office seem to be genuinely intrigued by how we work, although they often look on perplexed. They ask lot's of questions, they survey our
informative workspace and take the time to read our
information radiators as they pass by. Occasionally, one person comes and stands outside our
bullpen and gazes upon the
hustle occurring within. It's great. I don't think they get Agile yet but they're interest encourages and motivates us. And what's gratifying is that they tell us how happy and impressed they are with the work we do. It's wonderful to feel valued and appreciated. And it's great that they see the business value being delivered.
The team
played the XPGame the other night. That generated more interest amongst people in the office. Some of the business and management people have asked if we can run the
XPGame for them. This will really help them to understand how and why we work the way we do. As the Chinese proverb says:
I hear and I forget,
I see and I remember,
I do and I understand.
Links to this post
Change has to come from within
I believe a lasting change has to come from within. For change to happen, you've got to want it and you've got to take action to bring it about. If you don't want to change, it probably isn't going to happen.
An organisation needs to be in a state that is conducive to change before it can undergo change. That state is founded on trust and respect. It engages all people and refocuses their introspection and discussion on relationships and principles rather than on process.
Links to this post
Agile governance and planning probabilities
Mauro Talevi and I recently attended a session about
Agile Governance presented by
Jason Gorman. Read about the theories behind the games played in the session:
I recommend this session.
Tags:
agile,
adaptive planning
Links to this post
Playing the XPGame
We played the
XPGame last night with 2 teams of 4 people. Team A beat Team B. The
XPGame is always a huge amount of fun. And it's a great way to experience and understand the principles and techniques of adaptive planning and estimation. Lots of interesting comments and insights came out of the iteration retrospectives, and these mapped directly to situations and behaviours the team are experiencing in real-life work. What I found particularly interesting was that Team A described themselves as self-organising (and this was indeed what we observed as coaches) while Team B felt they missed the presence of a Team Leader. I don't think this is the only factor that contributed to the outcome of the game, but I'd like to run 3 more iterations with 2 people from each team swapping over. I wonder what would happen?
Here are the pictures from last night:
xpgame-sortingafulldeckofcards
Originally uploaded by sjb140470.Tags:
extreme programming,
xpgame
Links to this post
