Straight talking
When you don't know the answer to a question, don't be afraid to say so. Speculating is the worst thing you can do because it will probably set an expectation that you cannot satisfy.
If the Product Owner insists "I need this additional functionality by the end of the release". Don't try and be a hero by responding with something like "We'll give it a go". If you do, you'll be absorbing risk that is not yours to absorb. Stick with reality, be honest and deal in facts. In this situation, it would be better to respond with "Let me work with the team to determine what we can deliver in the remaining time, given your priorities". The team should determine what can be achieved so that they collectively commit to the deliverable.
When a problem arises or a risk becomes evident, make it visible by communicating it to the stakeholders and to the team immediately. It's important for the stakeholders to understand the potential consequences and for the team determine possible solutions at the earliest opportunity. If you have a medical condition that requires surgery, you should have that surgery as soon as possible to correct the condition otherwise the condition could worsen to the point of criticality. Avoiding a problem or hiding it delays the pain, which may amplify or compound the consequences.
Tags:
agile
Links to this post
Take a run up
The Extreme Programming corollary practice of Negotiated Scope Contract advocates fixing time, cost and quality while scope is negotiated on an ongoing basis. I am currently working on a contract which employs this practice. There is a contract per iteration which fixes time. The composition of the team is fixed per iteration therefore fixing cost. The quality is fixed by adhering to coding standards and ensuring a junit test coverage > 85% is maintained with the outstanding 15% corresponding to functionality that is unlikely to break.
However, before initiating the project the client was insisting on a cost for the project for budgeting purposes. At that stage a user story writing workshop had been completed so we had a large number of user stories but without story point estimates or any idea of the team's velocity. Rather than take a guess, the client was persuaded to fund iterations 0 and 1 so that the team could estimate all the user stories in story points and derive an actual velocity based on the user stories implemented and accepted by the onsite customer. A projected cost for the project was calculated by dividing the total number of story points for the remaining user stories by the team's velocity and then multiplying by the resource cost of the team members.
The client decided that the investment in iterations 0 and 1 was worthwhile because the subsequent estimates to size the overall project would be empirical, i.e. based on a measure of what had already been achieved by the team in iteration 1. The client recognised that having empirical estimates would provide a more realistic cost calculation, which in turn gave the client more confidence when budgeting.
Tags:
agile
Links to this post
Last night i had lots of fun at the '59 Minute Scrum' hosted by the BCS Spa specialist group. Our project was to produce a tourist brochure for Martians visiting earth. The product backlog included the following items:
- Create cover art, brand, and/or logo
- Define major topics for Martian tourism
- Describe "Art interests in Europe" tour
- Describe a tour based on photosynthesis
- Outline a "7 Wonders of the World" expedition
- Set prices for the tours
- Outline warning messages (gravity. oxygen, fungi, etc)
- Suggest clothing options
- Explain travel options to/from Mars
- Describe a "Human Sports" tour
- Outline refund policy
- Suggest related services
- Define advertisers
- Define a 12-month campaign
- Set-up how to get more information
Our Product Owner emphasised that in terms of business value, the most important thing was to get at least one tour operating so that revenue could be made to support various other tours. Our Sprint Goal was therefore unimaginatively titled "The First Tour". The Sprint Backlog included the following items:
- Create cover art, brand, and/or logo
- Describe a "Human Sports" tour
- Set prices for the tour
- Outline warning messages (gravity. oxygen, fungi, etc)
- Suggest clothing options
We managed to achieve the goal with some juggling of tasks guided by the Daily Scrums. Here's the cover of our first brochure:
59minutescrum
Originally uploaded by sjb140470. The event slides can be downloaded from
here.
Here are the original materials:
InstructionsProduct backlogsTags:
agile,
scrum
Links to this post
Test infection breeds quality
Generally, the acceptance testing and unit testing performed by an agile team facilitates collaboration and communication, creates feedback loops, and gives developers the courage to attempt things they would perhaps normally shy away from. A test-driven approach to development causes high-quality solutions and implementations to emerge.
Acceptance Testing:Acceptance tests are written by the onsite customer. This allows the onsite customer to inject their domain knowledge directly into the development effort. Acceptance tests are the result of the conversations prompted by the user stories, which occur between the onsite customer and the developers at the start of each iteration. They capture the details of the user stories and assert their behaviour, as well as defining the acceptance criteria. The acceptance tests also create a feedback loop between the onsite customer and the developers. The acceptance tests should be executed regularly by the automated build process. This provides greater visibility of progress to the onsite customer in terms of passing and failing acceptance tests. At the start of an iteration the acceptance tests will fail, but as more user stories are completed more acceptance tests will pass. Once an acceptance test passes, should it begin to fail (perhaps due to a recent change), the problem should be fixed immediately so that the test is made to pass once again. This continous and visible feedback enables the onsite customer to steer the iteration and development effort more effectively.
Using an acceptance testing framework such as
Fit allows the onsite customer to construct acceptance tests in a tabular format, e.g. a spreadsheet or HTML table. The developers then write fixtures linking the tables to the software under test so that the acceptance tests can be executed automatically.
See:
Fit LibraryFitNesseSeleniumDeveloper TestingWriting automated unit tests as part of test-driven development guide the evolutionary design of software and, by asserting class behaviour at a method level, provide effective documentation.
Developing software using automated unit tests is empowering because inside the test-driven cycle - test->code->refactor - they serve as constant indicators and reminders and allow developers to code, integrate and build in baby steps. Run frequently by the automated build process, automated unit tests provide a meaningful measure of progress. The unit tests should always complete with a 'green light'. Those that fail with a 'red light' should be fixed immediately so that working, executable software is always available. Automated unit tests, providing a very high code coverage (>85%), act as a safety net for developers. This safety net gives developers the courage to make changes because broken code is quickly highlighted and the cause is easily traced because the tests are run so often.
See:
JUnitTags:
agile,
tdd,
fitnesse
Links to this post
Forgetting to breathe can be hazardous to your health
Come up for air is a pattern for taking regular opportunities to communicate and to refresh awareness.
Before examining the pattern, let's take a look at a metaphor:
When snorkelling, you have to come up for air regularly otherwise a bad thing can happen. When up and before submerging again, you should check that it's safe to do so by surveying your surroundings and taking your bearings.Pattern Name: Come Up For AirSummary:During development, a developer should never miss an opportunity to communicate with the team and to raise his awareness of any tactical and strategic changes, recent decisions and the general project status.
Context:A developer is writing code alone to satisfy a number of tasks that he owns in relation to a particular user story.
Problem:Writing code is an intensive activity that requires deep concentration. A developer can become so engrossed in the coding effort that he can forget to Come Up For Air on a regular basis. Consequently the developer becomes disconnected from what is going on around him. Even when a developer disengages from the coding he can remain engaged by its details. Here's a story:
George has just got a green light on his unit tests and decides he needs a fresh coffee. Walking to the machine, George starts to think about his coding to-do list and the next code he needs to write. He's blinkered and unaware of the latest information in the team's
Informative Workspace and the chatter occurring amongst other team members. Without taking the time to look around, George misses the opportunity to catch up on things that may affect him sooner or later. While
Continuous Integration will highlight code divergence, perhaps he missed that key metric relating to progress in a
Big Visible Chart or that useful snippet of information from a conversation which should have influenced how he is going to approach the next piece of code.
Solution:Pair programming helps but an individual still needs to develop a personal awareness. Firstly, a developer needs to become tuned in to 'team chatter' while coding, absorbing any relevant information revealed by other developers through osmosis. Secondly, he should make a conscious effort to be frequently proactive and interactive beyond his pair programming partner. He should break regularly from coding activities in order to reacquaint himself with all team mates and the
Informative Workspace. Whether he simply sits back in his seat or gets up to stretch his legs, a developer should regularly consume all new information available and learn from it.
During a break from coding, try doing some of the following:
- Walk around the team's workspace taking time to appreciate the surroundings and the atmosphere.
- Absorb the information portrayed by the Big Visible Charts and other Information Radiators in the Informative Workspace.
- Make conversation with other team members but do not interrupt those with 'heads-down' or those in the private area of the workspace. Keep in touch with any remote team members using an instant messenger, phone or video phone facility.
- Observe any white board sessions engaging some of the team members, and do not be afraid to get involved.
- Seek advice and opinion, and offer it when it is requested or you deem it pertinent or useful.
- Check your email for communications from other team members and project stakeholders.
- Assess everything seen or heard with reference to the sprint/iteration plan and the big picture (product backlog or release plan) to identify any potential impact, risks or obstacles.
- Take a holistic snapshot of key metrics, e.g. test coverage, acceptance test pass/fail rates, etc. Update any Information Radiators or data associated with Big Visible Charts.
Consequences:As each individual developer operates at a higher level of awareness, he will become attuned to the team's collective effort and goals. Each developer will see and understand more than just the bubble defined by the tasks they own. As each developer tunes in, the team will start to resonate, generating a 'buzz' as communication, confidence, visibility and productivity increases.
Tags:
agile,
informative workspace,
information radiator,
big visible chart
Links to this post
Mind mapping the sprint goal for a big visible chart
I've used mind maps to do many things, from constructing daily plans and to-do lists to study and revision to planning a party. Recently i started to use a mind map to portray a visualisation of the Sprint Goal.
After a day of sprint planning sometimes the team can sometimes become immersed in detail and lose sight of the big picture. I like to conclude the sprint planning by reconvening with the product owner to collectively declare the sprint goal, bringing the big picture back into focus. While the sprint goal defined in text can be concise, it does tend to be a rather dull artifact. And generating the sprint goal doesn't generate much excitement or enthusiasm at the end of a long day. Mind mapping is an effective way of focusing your thoughts to rise above the detail and return to the big picture. The visual product is a far more interesting artifact than a statement and it's fun creating it. The conclusion of sprint planning is a satisfying achievement in itself, but the fun element of mind mapping as a group seems to recharge everyone before they go home.
The sprint goal needs to be omnipresent during the sprint. As the sprint progresses, the team repeatedly assess the remaining work and evaluate the completed user stories to ensure that, in some shape or form, the sprint goal is being satisfied. Referring to a visual representation of the sprint goal rather than reading text from the planning board or tool, or recalling it from memory is more effective and more pleasing. Omnipresence is more easy achieved with a big visible chart so draw the mind map on a whiteboard.
sprintgoal
Originally uploaded by sjb140470.Tags:
agile,
scrum,
mindmap,
big visible chart
Links to this post
"Truth is a conversation about things that matter" -- Parker Palmer
I recently explored a reference to Parker Palmer's "To Know As We Are Known". I was interested to read that Parker, a renowned educator, defines truth as an "ongoing conversation about things that matter" and sees "education creating an environment in which truth is practiced". As i was reading i found myself thinking of Scrum and the anecdotes told by Ken Schwaber in the CSM course i attended.
As an example of scrum's honest approach ... yesterday i talked with my boss, ahead of an important meeting with the client, to review our sprint achievements to date and the work remaining. I pointed out that while we had achieved everything the client had prioritised for the sprints to date, given our velocity and the remaining story points and projecting forward it was clear that not all the stories would be completed before the client's budget emptied. The key question for my boss was "Would this be a surprise to the client?" My answer was "No". As i expected, the meeting with the client was very constructive. The visibility of progress and level of participation by the client throughout the project meant that, going into the meeting, the client already understood the status. Consequently, the meeting focused on reprioritising the product backlog to maximise ROI for the remaining budget, and on identifying remaining risks and obstacles and how to remove them. It's a pleasure to work with clients who recognise their role in and responsibility to the project.
It's just a shame how some people/companies still stick their heads in the sand and prefer to hear embellished half-truths that hide the facts. Don't give them what they want. I believe you must be honest from day one and, importantly, honesty _must_ be surrounded by visibility. Unfortunately, speaking from experience, honesty can sometimes put you in situations you'd rather not be in when dealing with 'head-in-sand' syndrome. But do not compromise on your values. I believe honesty is always the best policy and at the end of the day it's their loss and not yours.
Tags:
agile
Links to this post
Here's an extract taken from an excellent article,
Making the date by Ron Jeffries.
From the viewpoint of the Customer, the development organization is like a washing machine. The machine will take a batch of clothes, up to some maximum size, and 30 minutes later, the clothes are washed. To wash that many clothes that well, we can't get the machine to do it in 10 minutes, or even 20. We can try to jam a few more clothes in, and for a while it will work, but there really is a maximum beyond which the machine starts jamming, tearing up the clothes, and not getting them clean.If we're faced with 10 batches of clothes, it's going to take five hours to get them all done, if we're totally on top of the machine every minute. If we only have three hours before we have to leave for the wedding, we'll need to decide which clothes to do, and which ones to defer until next Monday. We can do six batches, no more. No amount of holding the machine's feet to the fire will make it do any more, and with a little bad luck we'll burn a wire and it won't work at all. Plus foot-burning takes time away from getting the wash done.Our job as the Washer Customer is pretty simple, once we get over any delusions of having power over the machine. We need to select six batches of clothes that will do the best job of serving our needs at the wedding, and until next Monday. And, if we're wise, we'll even front-load (no pun intended) those batches, to put important items in the first few batches, just in case something goes wrong and we only get four or five batches. Maybe we need to go to the store while one of the batches runs. If so, we might want to make sure we get a complete outfit out of the first couple of batches.The software situation is quite similar. View the development team as a machine that produces nice clean features. Pick features with two things in mind: Make sure we have all the key features by the final deadline, and try to batch features so that usable subsets of the product arise every few iterations. Now, it's possible to push the washing machine metaphor a long way, and get some benefit. - Shouting at the machine won't help. It's going as fast as it can.
- Taking the machine apart in hopes of speeding it up will guarantee that you get less wash done by the time the three hours are up.
- Buying a new machine may help you later, but it won't help you today.
- Keeping the machine well-maintained will serve you over the longer term.
- Small maintenance steps, like cleaning the filter, may even help over the short term.
- If we forget to do something important, like shirts, until the last batch, there's a good chance we're going to look bad at the wedding.
Well, let's not go nuts here. The point is that if we, as the Managing Customer, focus mostly on getting the batches right, we'll come close to doing the best possible job of meeting the goals on time. If we're a bit clever with mixing the features in the batches, we can even have interim releases ready to go, for special needs and opportunities.
washingmachine
Originally uploaded by sjb140470.Tags:
agile
Links to this post
Track remaining effort in hours not days
I have always tracked the
remaining effort to complete an engineering task in ideal hours rather than ideal days. However, the current project I'm working on is using real days as the unit. The switch back to real time from ideal time is consistent with Kent Beck's latest approach to estimation. Regardless of whether ideal or real time is used, I prefer tracking the remaining effort in hours and not days.
My development style is test-driven but i have a 'track' action at the end of my test-code-refactor cycle. Within a disaggregated user story, I approach each engineering task by formulating a number of code-and-test goals that build on one another to evolve the task to completion. When I attain each goal I record my effort and re-assess the remaining effort to get the task completed in my tracking data (I use
V1:Scrum). My goals are small enough that, on average, they take me between 30 minutes and 2 hours to achieve. Therefore, tracking this frequently and in hours generates more accurate data from which to draw my future empirical estimates.
The engineering tasks and associated tracking data are private to the team and are not part of management reporting. I report progress to management in story points.
Tags:
agile planning
Links to this post
Before adding more resources to a project team to accelerate delivery have realistic expectations about the effect. Measure the impact of learning curve and management overhead and be sure that the increase in productivity is worth the additional expense.
A recent study by QSM collected data from 564 projects completed since 2002 and revealed that large teams don't complete projects much faster than small teams. But they are significantly more expensive. Teams with around 34 people on average completed a 100,000-line project in 5.6 months at a cost of $2.1 million, while teams of around 4 people on average took about two weeks longer but cost just $294,000. Thus, shaving two weeks off the schedule cost some companies as much as $1.84 million.
Read the
article.
Links to this post
