Poster at d-tools
Adam at
d-tools was kind enough to send me this photograph of my
Baker's Dozen poster up on the wall in his office. My thanks go to Adam for requesting A1 posters and for his patience while I sorted stuff out.
The
Baker's Dozen poster is on sale
here. The
Compromised Agility poster is also available but not from our online shop. This is easily rectified if we get enough interest.
Planning Poker cards next. And I'm also toying with the idea of a
Retrospective Prime Directive poster.
Tags:
poster
Links to this post
Vertical slicing
Develop a
user story incrementally using a technique called
vertical slicing. Drive a thin vertical slice through the story, from UI to DB, which is functionally coherent and demonstrable then progressively widen with consecutive slices.
As
Paul Hammond describes in his example:
When coding a login screen, simply show the username box and a button and allow a login with just the username typed (no checking). Then add a password box and still allow the login with no checking. Then have the user enter a username that is checked. Then a password.
Be sure to
get feedback after every slice is completed. Ask a tester to perform some exploratory testing. Get a web designer to eyeball the UI. Demonstrate the emerging functionality to the
Product Owner. From his perspective, it's like watching a picket fence being erected. After a few slats are installed a picture will form in his mind of how the end product will look and, based on that, the feedback provided will give you a steer going into the next slice.
Tags:
vertical slice,
user story
Links to this post
It's showtime
We run our
showcase from 4:30 to 5pm on a Tuesday (the
last day of our
weekly iteration). At 4pm we prepare the showcase and run a rehearsal so that the sequence of demonstrated stories flows smoothly and delivers a narrative. Our first showcase was a popular event. So many people attended that they couldn't all fit in the room.
The
Product Owner kicks off the actual session by introducing the iteration goal to the customers and product stakeholders. Then each story owner introduces their story and conducts a demonstration of the functionality they have delivered, fielding questions as they go. At the end, the Product Owner publicly accepts (or rejects) the iteration deliverable, giving permission for it to go live (or not).
I like the story owners to present their stories because it gives them an opportunity, in the limelight, to strut their stuff and show off the results of their hard work. It helps support accountability within the team and it gives them a sense of closure. It also lets the stakeholders know who they are.
Tags:
iteration review,
showcase,
show and tell
Links to this post
We've always used
Cruisecontrol but in the last project we spent a lot of time deep in the code and it stank, big time. So despite, the
facelift, we've decided to try
Hudson on our new project.
So far, so good. We've got our avatars on the big visible build screen and we've got some new
build hats from the
Oktoberfest.
Links to this post
The power of colocation
Brian Marick recently blogged about
power steering in reference to
that old XP metaphor of the Customer driving the project like a person driving a car. He says: When you drive, you don't think about the steering wheel, you simply think about turning the car, and it turns. But when the power steering goes out, what was once a simple reflex is now a conscious act.
In our new office, we're colocated with our
Product Owners, our Product Sponsor, and our customer. The opportunity to be colocated to this degree doesn't happen often. It's usually obstructed by silly reasons such as office politics, silos and hierarchy, or
part-time team members from the business side having to be located elsewhere. Our thanks go to our client for recognising the benefits of colocation and for wanting to do things properly. Everyone is buzzing about the approach we're using and I'm excited about facilitatating
power steering to achieve continuously improving levels of
customer collaboration and feedback and value flow to our customer.
Tags:
colocation
Links to this post
Humble beginnings
We recently started working with a new client and have been located in a new office. The pictures below were taken on the first day in the first hour with people busy setting up their machines. We'll be starting
Iteration Zero on
Wednesday.
The default back-to-back 'workbench' layout is not ideal. There's very little room for
timeouts and huddles, the space for
stand-ups is not sufficient and there's no open space where communication convection can swirl as in our preferred
bullpen layout. We'll run with it for now because we can't physically separate the desks without them collapsing - each pair of back-to-back desks rests on a shared central spine. Apparently, there are moves afoot within the organisation to reassess working environments generally, and I understand that special considerations may be possible for agile teams. So I live in hope of changing the desk arrangement, but the
furniture police point out that we'll need to buy new desks and that makes it a budget issue for now.
At least we have one of our
planning boards to put our goal roadmap on. Visibility on day one. I'm liking that and so are our two
Product Owners.
Tags:
bullpen,
planning board
Links to this post
Self-discipline or just discipline?
A short while ago,
Brian Marick identified
discipline as one of
four values missing from the
Agile Manifesto.
Brian was recently asked:
How do you feel about the qualifier "self-" as part of "discipline"?
Here's his response:
If self-discipline has the connotation of doing [good thing] and not [bad thing] because of one's Steely Will, I think, in the immortal words of Rockett J. Squirrel: That trick never works.
I think self-discipline has that connotation. I prefer the kind of discipline that relies on things external-to-the-self:
- Pairing because it makes it harder to not write unit tests.
- Having to deliver business value at fixed deadlines because that doesn't allow certain kinds of sloppiness.
- Having big visible indicators when the build fails.
- Putting critical data on the walls between the executive offices and the bathrooms or kitchen so that everyone knows what's going on.
The simple and probably best way of looking at this is that it's not the self-discipline of the individual that's interesting; it's how an individual enlists the outside world (people and things) to provide a discipline that makes up for that individual's lack of Steely Will.
Tags:
discipline
Links to this post
A Product Owner has many skills
The
Product Owner needs a blend of the skills usually separated by traditional roles, should have empathy with the customers and and should have some knowledge of how software is developed and deployed.
Product Owner Skills
Originally uploaded by sjb140470 Product Management- Synthesises the needs of the customers and the various stakeholders.
- Performs competitive research and analysis.
- Assists with product marketing strategy and devises pricing model.
- Conducts acceptance tests.
- Demonstrates the product to customers.
- Collects customer feedback and transforms it into new features or enhancements.
Project Management- Responsible for the business value delivered by the team.
- Helps the team plan the content of each iteration given costs (estimates) and risks.
- Provides feedback and makes decisions that steer the team based on what's delivered every iteration.
- Communicates progress to the Product Sponsor and stakeholders.
Programme Management- Why not put the Product Owner in charge of the budget? After all, he is responsible for maximising return on investment in every iteration.
Business Analyst- Articulates the product vision and business strategy to the team and defines goals that realise the product vision.
- Writes and evolves user stories to a suitable level of detail given their position in the Product Backlog.
- Communicates the details of the user stories so they can be captured as acceptance tests.
- Prioritises user stories in the Product Backlog by business value.
- Manages the Product Backlog in response to changes.
Business Intelligence- Collect information about the product to help make better decisions relating to future functionality and business value.
Tags:
product owner,
scrum
Links to this post
Accountability != Responsibility
Via
Christopher Avery.
Accountability is an agreement to be held to account by another for your operations or the results you produce. If meetings are called to determine who was acccountable, you're looking for people who are trying their best to hide. Not the sign of a healthy culture.
Responsibility is a feeling of ownership and stands out when you are leading, learning, correcting, and improving. The sign of a healthy, high-performing culture.
Tags:
accountability,
responsibility
Links to this post
Treat estimates as solution budget
Jeff Patton gives us some good advice about how we view our estimates:
Treat estimates as a budget for some possible solution, not as a bid for one specific solution.
Tags:
estimation
Links to this post
Have you compromised your agility?
Our session -
Have you compromised your agility? - has been accepted for
XP Day. I'm surprised though because there wasn't a great deal of wiki-discussion about the session during the selection process. I know
Steve Freeman championed the inclusion of our session and so our thanks go to him. Hopefully it will contribute to a provocative and constructive end to the event that will see the debate extend to the pub afterwards. The plan is to roll our session and Steve's session - Have we lost our mojo? - together to discuss the notion of
compromised agility and raise questions about the current state of the Agile community.
I couldn't resist creating a poster with a version of our
handbook. We plan to make these available for sale and we might even have a few at the conference. If anyone is interested in purchasing a poster, please send me an email at simon at energizedwork dot com.
Links to this post
Corporate idiocracy
A month or so back, a recruitment agency contacted me and asked if they could put my CV forward for a Scrum role at a large client. Apparently the client was about to kick off a project and wanted it to be agile. I said yes and then never heard anything for 2 weeks. I chased the agency up for some news or feedback and was told:
The client is debating whether it needs a Project Manager with Scrum experience or a Scrum Master.
I responded:
Sounds like they don't really understand Scrum.
The agent replied:
I think they'd be the first to admit they are lacking in understanding, which is why they want to hire external expertise.
This organisation wants a project to be agile, to follow Scrum specifically. They know they know very little about Scrum and they decide to hire someone who does. So, if they know they don't know about Scrum what makes them qualified to decide whether they need a Project Manager with Scrum experience or a Scrum Master?
Scrum doesn't work without a Scrum Master! It does work without a Project Manager.
Tags:
scrum
Links to this post
Mary Poppendieck at the Agile Business Conference
Here are some notes I took during
Mary Poppendieck's keynote speech comparing Lean Product Development and Lean Software Development:
- Change isn't the enemy. Anticipate change. It's there to make things flexible. The 'soft' in software is there for a reason. Software is meant to change so stop trying to nail everything down. Write change-tolerant software by employing change-tolerant practices.
- Complexity is the enemy. Perfection is achieved when there is nothing left to take away. Write less code. Build what you need now and don't build today what you might need tomorrow - just-in-time not just-in-case. Add features only when you really need them - no features ahead of their time; no features after their time.
- The rhythm of doing iterations helps to level the workload by establishing a predictable workflow and a reliable pace. Don't force an increase in the workload beyond what can be achieved with a sustainable pace.
- Create a stop-the-line culture. Invest is systems that detect the moment a defect is infected into the code, and then fix it.
- You won't achieve fast throughput by maximising person utilisation.
- If your more than 10% of requirements are changing as you progress, you've specified them too early. If you have separate test and fix cycles you're testing too late.
- Think 'systems'. Build complete systems, not just the software. Focus on the flow of information otherwise you'll realise Conway's Law. Crisply define value. Don't batch-and-queue. Appreciate the lifecycle.
Tags:
lean,
agile business conference
Links to this post
Ken Schwaber at the Agile Business Conference
At the
Agile Business Conference,
Ken Schwaber in his workshop - When will Microsoft go out of business? - said 2 things I liked:
There's no good news. There's no bad news. There's just news. (Understand it. Determine if you need to do something. And do it.)
Scrum doesn't engender excellence. It exposes incompetence.
Tags:
scrum,
agile business conference
Links to this post
You can't own something part-time
On the first day of the
Agile Business Conference,
Roman Pichler talked about the Role of the Agile Product Owner. It was a succinct presentation of the basic responsibilities of Scrum's
Product Owner role. Roman conveyed the likelihood that the Product Owner would not be available all of the time (he mentioned hot-desking) nor be colocated with the team. He showed a hypothetical calendar day for a Product Owner that had an hour blocked out in the morning dedicated to collaboration with the team. This set-up is a reality for many companies, indeed it's probably the accepted norm.
That's bad! The Product Owner should be a full-time member of the team and be colocated with the team. If he's not then, in my opinion, the team's
agility is compromised. The team cannot possibly achieve all that they are capable of achieving on the project. Time-boxing interaction between the team and the Product Owner constrains collaboration with the business. In my mind, collaboration is not something that you turn on and off depending on the time of day. It's a hive of conversation and activity that permeates the environment generating
hustle. If you want to achieve hyper-productivity, one of the things you need to be able to do is talk with the Product Owner, as and when you need to, and to demonstrate
vertical slices of a
user story many times a day to get feedback.
If the project is vital to the business, then the company can always find a way to provide a full-time and colocated Product Owner. If they say they can't, it really means they won't. Quite simply, they're not prepared to do what is necessary to achieve it, and frankly, if they're not going to take the project seriously why should you? Usually, the obstacle relates to a silo'ed organisation where departments are arranged by role rather than product stream. Hardly an insurmountable obstacle ... really.
Tags:
scrum,
product owner,
compromised agility,
agile business conference
Links to this post
At the Agile Business Conference
For the last 2 days I've been at the
Agile Business Conference. After last year I said I wasn't going to go this year but I was tempted by the prospect of seeing
Ken Schwaber and
Mary Poppendieck again. I've heard the material before, but they're both engaging speakers and I was pleased that they were speaking at this conference because the audience is primarily business and project folks rather than the techies you get at
XP Day.
On the whole, for me, the conference was "same old, same old" but I still left happy. Why? Because there were 2 sessions about Lean. First, Mary Poppendieck's keynote speech comparing Lean Product Development and Lean Software Development. Second, experience reports from BT and Lloyds TSB about their use of Lean. Lean needs more exposure because more people need to know about it.
Tags:
agile business conference,
lean
Links to this post
Baker's Dozen poster
If you're in the US, this poster is now available to purchase online at
our shop. If you're in the UK, I have prints available for purchase. Just drop me an email at simon at energizedwork dot com.
A friend suggested I make a poster of
Baker's Dozen. So here it is:
Links to this post
