Tag: scrum

Tuesday, October 20, 2009

Two stand-ups a day

Posted by Simon Baker
For a long time now we have run 2 stand-ups every day, first thing in the morning and first thing after lunch, always at the same times and always around the board.
Read more... Comments: 2

Tuesday, August 4, 2009

Scrum Mastering isn't a part-time endeavour

Posted by Simon Baker
Tags: scrum
Don't be a part-time scrum master because you can't see the picture when you're in the frame.
Comments: 1

Tuesday, November 25, 2008

Dilbert does ham and eggs

Posted by Simon Baker
Tags: scrum

Sunday, October 7, 2007

A Product Owner has many skills

Posted by Simon Baker
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.

Friday, October 5, 2007

Corporate idiocracy

Posted by Simon Baker
Tags: scrum
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:
Read more... Comments: 4

Thursday, October 4, 2007

Ken Schwaber at the Agile Business Conference

Posted by Simon Baker
At the Agile Business Conference , Ken Schwaber in his workshop - When will Microsoft go out of business? - said 2 things I liked:

Wednesday, October 3, 2007

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.

Monday, September 10, 2007

Steer based on visibility and regular feedback

Posted by Simon Baker
Via Agile Advice .

Saturday, September 8, 2007

Don't do Scrum without XP

Posted by Simon Baker
I've been doing XP since 2000 and Scrum since 2004. I've never done Scrum without XP and, these days, I don't think of them separately anymore. I guess over the years they've merged into one for me and matured into my own concoction of principles and practices, still largely based on the Manifesto , enhanced by lean thinking , and extended with my own bag of tricks devised through tough commercial experience. I have to agree with Jeremy Miller, Scrum is fine but don't leave the XP practices at home . Actually, I think Scrum is great but, to be honest, I'd feel very nervous doing Scrum without the XP practices because I care about software . In many teams, doing Scrum without the XP practices would just produce crap code more effectively. If you want to do Scrum, I strongly recommend that you do the XP practices too. I do think Scrum's 30-day Sprint duration is too long. In my experience, I always saw Parkinson's Law and Student Syndrome set in during the 30 days. If you're new to iterative development , by all means start with monthly iterations but make it a top priority to achieve weekly iterations (as used in XP). If you're using weekly iterations but it's not possible to 'ship' working software to your production environment every week, try using Scrum's monthly cycle as a release cycle containing four 1-week iterations. Obviously it's preferable not to queue the output of iterations but the queue is manageable at 4 weeks worth of working software, and releasing monthly drums out a release rhythm and allows you to establish at least some incremental flow of valuable marketable features to customers. This is better than releasing sporadically based on marketing dates and having to use much larger queues while delivering zero value to customers for longer periods of time.

Friday, August 10, 2007

Grow a whole dedicated team around a single product

Posted by Simon Baker
If your people are organised by function rather than along product lines then you are fostering a silo mentality, creating artificial barriers and introducing coordination overhead. Give responsibility for each product to a cross-functional team with full-time members, located together in one place, who possess all the skills required to deliver product frequently to your customer. If a committee makes business decisions for each product then you will see a lack of authoritative decision-making and a loss of direction and urgency, resulting in delays and rework. Empower a single person , collocated and available for discussion, to own the product, champion its vision, maintain a visible backlog of requested work items prioritised by value, and steer development by making business decisions quickly.