New Year's Eve in Vienna
It's New Year's Eve here in Vienna and I don't have a lot of time today. There's a big dinner organised for tonight and we're off soon to take in a few beers on the
New Year's Eve Trail around the city centre landmarks. So I'll leave you with this little nugget:
Reducing adhoc testing is like trying to lose weight by giving blood.Happy New Year!
Links to this post
Giving trust
The best way to gain trust is to give trust.
Tags:
agile,
trust
Links to this post
Leading the way
It doesn't take power or authority to demonstrate leadership. The most effective leadership depends on the ability of an individual to recruit others to a particular course of action through persuasion and negotiation, and not by enforcing compliance because of some authority.
Leadership begins with the portrayal of a vision that connects 'what is' with 'what could be'. People will join the cause when the connection is meaningful and the goal is realistic and achievable. Given a shared vision, leadership delivers a clear direction forward with anticipated difficulties and challenges communicated up-front. People will more readily accept short-term pain in return for longer-term benefit if it's expected. However, without follow-ups that facilitate engagement and provide encouragement, any demonstration of leadership is just empty posturing.
Tags:
agile,
leadership
Links to this post
Take a chance
Empowerment involves taking a risk because the power granted includes the power to make mistakes. When a
Scrum team is empowered it's granted the authority to decide how best to achieve the sprint goal, and it's acceptable to fail sometimes but only in the interest of learning.
Tags:
agile,
scrum,
empowerment
Links to this post
Snowing in Vienna
So I'm sitting in our flat in Vienna, full to the brim with days of great food and the world's best beer - Puntigamer - and it's started snowing. Yippee! This time of year should never be without snow. I haven't had any opportunities to blog because, if I haven't been out doing stuff, I've been doing German lessons on my PowerBook and watching TV in German.
I got a free day tomorrow so I might get around to blogging if a few cheeky beers don't get to me first.
Links to this post
Getting to know people
When I start on a project as a
Scrum Master, I want to get to know the people I'll be working with as quickly as possible. Beyond the basic introductions, I perform the following activities with the
Scrum team and
Product Owner:
- I ask each team member how they would like to receive feedback. I also ask them if they would be willing to give me feedback. We then agree an informal contract which allows us to discuss issues easily and honestly.
- I ask each team member to complete a motivation exercise and to share the results with everyone. This helps me and the other team members understand what excites and what deflates a person.
- I ask each team member to complete a simple questionnaire based on the Myers-Briggs Indicator and to share their type (an alternative type description is available here) classification with everyone. This helps me and the other team members understand the styles of interaction that other people prefer to employ.
I also like to have weekly one-to-one meetings with the
Scrum team members and the
Product Owner. These take no longer than 15 minutes each, and are peer-to-peer and, in some cases, coach-to-coachee sessions that aim to be mutually beneficial. They provide a forum in which to discuss any issues or topics, and to provide feedback, privately.
Tags:
agile,
scrum
Links to this post
Slop and slack
Michael Feathers identified
iteration slop as the time spent before an iteration, preparing for it, and the time spent after an iteration, finalizing the work.
On a current project, the team have been suffering with post-
iteration slop. A retrospective identified some possible causes. First, under pressure to deliver the maximum business value in every iteration, very little slack was being included in the iterations. Second, iterations became overloaded because, as new information emerged about user stories through ongoing conversations with the customer, there was a tendency not to reassess the task estimates and the iteration plan, and adjust them accordingly. This resulted in user stories not being started and being descoped from iterations.
James Shore talks about the
slack and scheduling problems and describes a more deeply rooted problem: "I've seen a number of XP teams that regarded the iteration plan as no more than a rough guide. They thought that, if they didn't finish all of the stories in the plan, that was okay ... 'we're agile!' ... postponing stories to the next iteration was an acceptable (and frequently used) option. The whole point of an iteration timebox is to provide a hard deadline. Timeboxes are a proven technique for helping a team focus on the really important stuff. If you're always letting stories fall over to the next iteration, you don't have a timebox at all. Slack enables you to deliver even in the face of unexpected delays."
The team is now including slack in each iteration having persuaded the customer of its importance, and the content of the slack is agreed with the customer during the planning meeting. The team is also trying to improve discipline around maintaining and adjusting the iteration plan to more accurately reflect the remaining effort. However, another cause of
iteration slop, which is proving more difficult to eliminate, is a lack of ad-hoc functional testing performed in parallel with development. The end-of-iteration reviews with the customer reveal functional defects that should have been detected and fixed within the iteration.
Michael Feathers comments on this situation: "Some teams end up relying on their post-
iteration slop. It may not be a conscious thing, just a little bit of decreased diligence. But, unfortunately, often that is enough to completely muddle any sense of
done on the team. 'Yes, we are done', the team says at the end of the iteration, 'we passed all our tests', but the bug backlog silently increases, quality goes down and the project heads toward ruin." He suggests, "sometimes the best way of dealing
iteration slop is to just slowly reduce it".
Without dedicated testers, it's up to the team to work more carefully to avoid creating defects. An added benefit is that the customer is willing to test user stories as they evolve during development. The aim in January, when the project resumes, will be to reduce the overall number of defects and, consequently, to decrease the amount of time spent fixing defects after the iteration review.
Tags:
agile,
extreme programming,
slack,
iterative development
Links to this post
What does it mean to be empowered?
Understandably, some developers who come from a command and control environment are uncomfortable in a self-organising team that empowers developers. In a recent post to the
scrumdevelopment newsgroup about
coaching a developer away from being spoon-fed, an interesting discussion ensued about what it meant to be an empowered developer on a
Scrum team.
empower -
verb to invest (someone) with the power and authority to do something.
Martine Devos questioned whether Scrum Masters sometimes just try too hard. Certainly pushing empowerment can generate resistance in the people we are trying to empower. It needs to happen naturally. But coaching can help. As Dave Bly said, if you have teenage children, you know that they don't always listen to you or heed your advice, no matter how much you talk or shout. Sometimes it's just better to let them 'stub their toes' a few times and learn for themselves. The trick is to find ways to help them learn from their failures in small and non-destructive ways.
Power can be ascribed by position. This type of power is given to you by being part of a self-organising
Scrum team. Is this power important? Yes it is. But Martine identifies an inner power that everyone has, regardless of position, and this is important too. She says nobody gives you inner power because someone tells you that you're empowered. You get your inner power when you face your fears and act anyway. Personal power is fuelled by your ability to perform and your insistence to communicate freely, even in a command and control environment. Having positional power isn't worth much if you can't bring your personal power to bear. In an empowered, self-organising
Scrum team you first need to recognise and embrace your inner power, using it to good effect, before you can use your positional power and operate and behave as an empowered member of the team.
Perhaps, as Scrum Masters, we should be more prepared to take a step back and give the
Scrum team the space and time to unfold and learn to work as a team, while each team member finds their personal power and becomes empowered. The problem is, in the real world, in a commercial environment, you can't wait forever.
Tags:
agile,
scrum
Links to this post
Feelings of worth
Feelings of worth can flourish only in an atmosphere where individual differences are appreciated, mistakes are tolerated, communication is open, and rules are flexible - the kind of atmosphere that is found in a nurturing family.
-
Virginia SatirOr in a functioning scrum team.
Tags:
agile,
scrum
Links to this post
He says "The changes aren't substantial, particularly to the core sections, but I've made more noticeable changes to the the survey section, including talking briefly about the second edition of extreme programming."
Take a look at
The New Methodology.
Tags:
agile
Links to this post
Change
Change happens one person at a time.
-
Virginia Satir
Links to this post
Seeking improvement and receiving feedback
In XPv2,
Kent Beck identifies
improvement as a principle. He says "there is no perfect process, there is no perfect design, there are no perfect stories. You can, however, perfect your process, your design, and your stories". You can also perfect yourself.
It's important to learn and improve. I want to continually improve as a team member, as a scrum master, as a coach, and as a person.
Feedback is a value of XP that provides a mechanism which facilitates improvement. Don't be afraid to ask someone for feedback. However, recognise that it takes courage to provide feedback, so make it easy for that person to give you feedback. If it's general feedback you want, try explaining what motivates you and demotivates you. If you have your own ideas on areas in which you could improve volunteer that information.
When receiving feedback, listen actively and receive it genuinely without being defensive. Seek explanations and specific examples and show your appreciation by following at least some of the advice. You should endeavour to make visible improvements based on the feedback.
Tags:
agile
Links to this post
Serenity isn't freedom from the storm, but peace within the storm
Amidst the storm of unpredictability that is software development, you can find calm and control by using
Scrum. An empirical process such as
Scrum uses honest feedback, and frequent inspection and adaptation to control progress in an unpredictable environment.
Feedback is obtained from
iterative development that delivers tested, integrated and working software every 30 days. As Ken Schwaber says "there's nothing like a tested, integrated system for bringing a forceful dose of reality into any project. When people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements".
Frequent and regular opportunities are available to inspect and adapt, to check progress and alter direction or to modify the process. Everything regarding the project is kept visible. If there's bad news, it's better to know about it as early as possible while there's still time to address it. On a daily basis there are the scrum meetings and at the end of each iteration or sprint there's the review meeting and the retrospective. Adaptive planning is used to keep long-term plans fluid, while the planning meeting at the start of each sprint produces a stable plan for that sprint only.
Further reading:
Mishkin Berteig writes about
Agile Work Uses Lean Thinking - Empirical Process ControlTags:
agile,
scrum,
iterative development
Links to this post
Teamwork and trust
Jeffrey Phillips says
It's a matter of trust.
This is a very insightful post, and 2 things Jeffrey says resonate with me today. Paraphrasing ...
In a team, for each person to commit fully to the team, to the project, and to their work, they must be able to trust that those around them are doing their jobs well. Trust is earned. In part, trust is built by delivering on the commitments made to others. Say what you'll do and then do what you said.
When a person doesn't deliver on her commitments to the team, trust starts to falter and the whole team is effected because they placed their trust in each other. The team's effectiveness begins to diminish, their productivity decreases, and consequently their morale drops. In a previous post I asked
can trust be restored once it's lost? If it can't, the team enters a downwards negative spiral.
As Jeffrey says, each team member should start out by thinking "I want to work where I can fully plug-in to the culture and think that my belief in other people and their determination to do the right thing and to work as hard and as effectively as possible is the same as mine".
Tags:
agile,
trust
Links to this post
Simplicity, comments and refactoring
David Crow posts an article about Simplicity Rules. I like number 10:
Simplicity is about subtracting the obvious, while adding the meaningful
It reminds me of removing obvious comments from code and refactoring code to make it meaningful and self-documenting.
Here are Kent Beck's criteria for evaluating the simplicity:
- Appropriate for the intended audience: No matter how elegant a solution is, if the people who need to work with it don't understand it, it isn't simple for them. Do the simplest thing that works for the audience.
- Communicative: Every idea that needs to be communicated should be represented in the solution. The code should express the programmer's intentions and should communicate to the readers.
- Factored: Do something once and only once. There should be no duplication. Duplication of logic or structure makes code hard to understand and modify.
- Minimal: Working within the above 3 constraints, the solution should have the fewest elements possible. If you ain't gonna need it [YAGNI], don't do it. Fewer elements means less to test, document, and communicate.
Tags:
agile
Links to this post
How not to do it: Agile Development, Microsoft-style
Randy Miller at Microsoft writes about his
experiences with agile development. And Ken Schwaber comments about
Trends in Scrum and Agile.
Update:
John Nolan makes some
comments too.
Tags:
agile,
scrum
Links to this post
The illusion of fixed price contracts
Companies need to move away from using fixed price contracts where their expectation is, for a fixed price, they can have everything they ask for delivered on a specified day in the future. How did it get this way?
Managing software development using a defined process is an illusion. Developing software is inherently unpredictable. First, the term 'stable requirements' is an oxymoron. Requirements will change. Recognise it and embrace the inevitability of change. If you spend six months working on requirements in order to stabilise them, you're wasting your time. By the time you finish the requirements the business priorities will have changed, or the competitive landscape will have moved, or the targetted users now want something else. Second, estimating how long it will take to write a piece of software is difficult because it's a creative activity and not an exact science. It also depends on people who, contrary to popular belief in the industry, are not automatons or
plug-compatible-programming-units.
To manage software development effectively you need to use an empirical process that frequently inspects and adapts, rather than a defined process that attempts to predict. There's always a budget so fix the price of the project. Fix the time too, but agree that scope can be varied to protect the release dates. But this approach doesn't provide a guarantee that all the required functionality will be delivered. Correct! But this is true for a defined process too. If you thought otherwise you were living an illusion. Essentially, an empirical approach uses a feature buffer and prioritising the work in order of business value guarantees that some business value will be delivered by the release date, rather than see the entire release slip.
The project should be initiated against a high-level roadmap that identifies very approximate content that could be delivered by agreed release dates, with more specific content for each iteration being planned just-in-time. At the close of each iteration, a review is conducted for the customer to accept or reject the functionality delivered by the iteration. At this point, the customer should consciously decide whether to continue with the project or not. Too often the decision to terminate the project is ignored because people are afraid and do not want to acknowledge the smell of the
dead fish of failure.
Too many traditional fixed price (fixed time, fixed scope) contracts fail to deliver and their failure isn't evident until the release slips. If a project is destined to fail you need to smell and acknowledge the distinctive odour from the
dead fish of failure as soon possible. The best way to sniff out the smell is to make everything visible, inspect and adapt frequently, and use
iterative and incremental development to deliver working software rapidly and regularly.
Tags:
agile
Links to this post
Effective conversation
To make more effective conversation:
- Listen more. Being a good listener is half the battle.
- Speak less. Keep your own comments and questions short and to the point.
Tags:
agile
Links to this post
Your scrum team needs you
This is a companion post to
The courage to be creative.
Ken Schwaber describes the scrum master as a sheepdog who would do anything to protect the flock, and who never gets distracted from that duty.
The scrum master is the driving force behind scrum. The scrum team relies on the scrum master to ensure they live by scrum's values, enact scrum's practices, and abide by scrum's rules. The scrum master is responsible for bringing all the components of scrum together to function as a process. The scrum team's welfare is the scrum master's highest responsibility. He must demonstrate commitment to the scrum team so they can see that he's devoted to the team and will always protect and help them. However, if the scrum team breaks one of the scrum rules, the scrum master must insist that the team takes steps to ensure that it doesn't happen again. If someone isn't completing work, the scrum master takes the initiative and informs the rest of the scrum team so they can decide how best to help.
The scrum team looks to the scrum master to set them up for success. This is achieved by aligning roles and responsibilities, and organising and facilitating sprint planning meetings, sprint reviews and retrospectives. The scrum master helps the scrum team maintain productivity by removing obstacles, making prompt decisions when required, and by facilitating daily scrum meetings which provide a forum for the scrum team to synchronise, inspect and adapt. Engineering practices and tools are improved so that each increment of functionality is potentially shippable and progress is gauged by the scrum master and made visible to all parties with a public burndown chart.
The scrum master helps the product owner and the scrum team work together so that the product owner can drive the development effort directly. He also coaches the product owner on how to maximise the return on investment by selecting the most valuable product backlog to be developed in a sprint.
Tags:
agile,
scrum
Links to this post
Burt Reynolds was like a scrum master
In one respect the scrum master is like Burt Reynolds in the film
Smokey and the Bandit. Like The Bandit runs block in his black Trans-am for The Snowman's truck full of beer, the scrum master removes obstacles from the scrum team's path to ensure that the sprint proceeds with maximum productivity and without interruption and impediment.
So, if the scrum master is Burt, then the product owner must be Big and Little Enos Burdette. But who's Sheriff Buford T. Justice?
Tags:
agile,
scrum
Links to this post
Can trust be restored once it's lost?
You earn trust and that takes time, but you can lose that trust in a moment.
Can trust be restored once lost? Maybe. But how do you know when you're considered untrustworthy? Gerald Weinberg's Third Law of Trust states: People don't tell you when they stop trusting you. "If they don't trust you, why should they bother communicating with you?"
Still in doubt? Put yourself in their shoes. Would you put your "money in a bank that advertised: 'We've only gone broke once'"?
Tags:
agile,
trust
Links to this post
Under-promising and over-delivering is a process 'smell'
A short while ago I read a post by Skip Angel that talked about
delivering on your promises. It reminded me of a situation a colleague told me about where a scrum team was under-promising and not telling the product owner, so that they had a better chance of delivering or over-delivering. I posted a
description of the situation to the
scrumdevelopment newsgroup.
In the discussion that followed, Jef Newsom described the act of under-promising and over-delivering as a "process smell". He said "the intent is good, but the means is deceptive". It indicates "that you aren't comfortable being honest with the parties to whom you are committing to deliver", i.e. to the product owner.
It's the product owner's responsibility to decide on the content of a sprint based on business value and cost, given in terms of estimates provided by the scrum team. It's the scrum team's responsibility to provide a cap on the amount of work assigned to a sprint based on their velocity. To paraphrase Ron Jeffries - you can't put 10lbs of shit in a 5lb bag. When the content of a sprint is agreed,
the product owner must understand that it's an estimate and not a promise that it will all be delivered.
When the product owner wants to know what will be done by the release date and what will not be done, Ron Jeffries says "refer him to the burndown chart on the wall". Given empirical estimates and the tracking information produced by agile teams, the information in the burndown chart should be good enough, in most circumstances, to plan release dates by "drawing a line about there" in the product backlog.
The lessons to learn from this thread are:
1. Relationships are all about
open and honest communication and
trust. Keep everything visible and get any hidden feelings out into the open. Talk straight and leave your box of tricks at home.
2. There's a big difference between and estimate and a promise. Ensure that the product owner knows that the scrum team's commitment to deliver the sprint content is an estimate and not a promise. Otherwise, if the team fails to deliver the sprint content, the product owner will see the team as having broken their promise and this degrades the trust in the relationship.
3. Don't play the 'promise' game with the product owner. As Ron Jeffries says "we have better data to give them than most software organizations ever produce. Let's give them that, help them to interpret it. Let's not play a game we can't possibly win."
Tags:
agile,
agile estimation
Links to this post
Write production-ready code faster with TDD
It takes time to become proficient at test driven development. But it's worth the investment. I'm not convinced it makes writing code faster because, after all, it does require you to write more code for the unit tests. However, I am convinced it makes writing production-ready code faster.
Coupled with continuous integration, TDD shortens the overall software development lifecycle because it absorbs the explicit non-coding phases of waterfall software development and makes them an implicit part of writing code. Through refactoring, analysis and design are unified to become a low-level, recurring activity, which also keeps code tidy and self-documenting. Writing unit tests first, helps design testability into the code, while maintaining a high test coverage helps locate and fix defects quickly and reduce the number of implementation defects.
Tags:
agile,
tdd
Links to this post
Daily scrum haiku
I couldn't resist adding a third verse (although I'm not entirely sure Haiku have verses) to address the most common problem in daily scrum meetings ..
In the daily scrum,
each team member, standing up,
answers three questions
What was done before?
What am I doing today?
Are there obstacles?
Talk to each other
and not to the Scrum Master.
Sync up, don't report.
Tags:
agile,
scrum
Links to this post
Top trumps
Alistair Cockburn talks about
Agile Software Development back in July 2004. Alistair Cockburn is an interesting and insightful authority on agile development. Two things Alistair said stand out for me.
First, "people trump process" and "politics trump people". Read more about the
People Factor.
And second, that software development is a "cooperative game of invention and communication". Read more about the
Cooperative Game Manifesto.
Tags:
agile
Links to this post
Use index cards or a planning tool to plan iterations?
When I first started doing extreme programming back in 2000 we used index cards to plan iterations and a spreadsheet for tracking. After a while, we became frustrated with the overhead the spreadsheet introduced, and moved to an agile planning and tracking tool. As part of this transition, the use of index cards fell away. With hindsight, we used the spreadsheet incorrectly. We should've tracked our effort on the planning board and simply plugged the latest 'work remaining' figures into the spreadsheet every day to produce the required
Big Visible Charts, such as the
burndown chart.
The first planning tool I started using was
XPlanner (now hosted at
Codehaus). It was nice and simple but I didn't like the charts, so I moved to
Versionone. I started to ask myself
do agile planning tools fit in an informative workspace?So, in a recent project we've been experimenting with index cards to facilitate planning and a tool for tracking and producing charts. I prefer to use index cards for planning because they facilitate conversation and feed the whole dynamic generated in the planning meeting. Playing with priorities by ordering the cards on a table or on the floor is a simple yet effective way to visualise potential options for iteration or release content.
The main problem we've experienced with using both index cards and a tracking tool is that you have duplication - a story exists on a card and in the tool. This duplication bugs me. Also, we've only been entering stories and their estimates into the tool for the current iteration. This allows us to track the work remaining in the iteration in the tool which automatically generates an iteration
burndown chart for us. We couldn't be bothered to enter the other 100 odd unplanned stories in the product backlog that are already on index cards. A bad consequence of this is that the tool can't generate a product backlog
burndown chart for us. So I'm creating this manually, in a spreadsheet.
In a nutshell, it's gotten messy and I'm now thinking we should be using one or the other, index cards or a planning and tracking tool. The trouble is, which one? Some people on the team love their tools and want to continue to use
Versionone, while others want to use index cards and a planning board.
At
XPDAY5, I had a few conversations with experienced agile people who had different opinions about the use of index cards versus a planning tool. So, I had the idea for a future conference session based on the BBC's
Question Time programme. A moderator will elicit questions from the audience to drive a panel debate on the use of index cards versus planning tools to plan iterations. The panel will comprise agile experts and proponents of both methods.
Personally, I would like to witness this session to hear what other people are doing and what they are thinking. I also believe this would be an informative session for newcomers to agile.
Tags:
agile,
agile planning,
big visible chart,
burndown chart,
informative workspace
Links to this post
Agile in Austria
So, we're going to spend Christmas and New Years in our flat in Vienna and I'm wondering what the 'agile' scene is like in Vienna specifically, but also in the rest of Austria too. I love Vienna but I can imagine that if 'agile' was big in say, Salzburg or Innsbruck or somewhere near the Alps, I could combine my passion for 'agile' with my passion for snowboarding. This would present a serious temptation for me to move away from the UK. I'm sure my girlfriend would approve, although I think she'd prefer to return to her beloved Vienna.
There's one small snag. My German isn't great. Is this really a snag? I know that if I moved to Austria, being immersed in the language everyday would help me pick it up far more quickly than learning it in the UK. But then a few European opportunities have presented themselves to me recently, and they have not required German, French or Dutch despite being based in Germany, Belgium and Holland. So I ask myself, perhaps such opportunities exist in Austria where I can work comfortably in English, giving me more time to master German.
Then there's always Calgary in Canada. No language requirement. Plenty of 'agile' action there by the sound of things and only an hour's drive or so from Banff. And I do prefer snowboarding in North America to Europe.
Sigh! One day I'm going to have to do something about this.
Links to this post
Luke Closs of Sophos talks about their use of Selenium.
Here's the podcast:
Luke Closs talks about Selenium
Tags:
agile,
selenium
Links to this post
