Tuesday, March 29, 2016

No estimates?

Agile Estimating and Planning
Arriving very late at the #NoEstimates discussion I did some catching up on reading about it. There is a lot of interesting talk and thinking going on under the heading of #NoEstimates. Woody Zuill and Neil Killick are two of the most vocal proponents. The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

This is a great idea. I agree with it in certain context and situations. There are many reasons to support this idea. Lean principles generally lead to a continuous one-piece model of production flow. Kanban approaches generally limit work in process, and for small teams the ideal limit seems to be one. Neither of these approaches has any need to estimate how long something will take. Instead, they measure how long things take, in “cycle time”, and use that to make such predictions as are necessary.

At the other hand there are numerous ways estimations (on a project level) are used by businesses and they will not dissapear soon.

- Allocating budgets to projects (i.e., estimating the effort and budget of each project)
- Making cost/benefit decisions at the project/product level, which is based on cost (software estimate) and benefit (defined feature set)
- Deciding which projects get funded and which do not, which is often based on cost/benefit
- Deciding which projects get funded this year vs. next year, which is often based on estimates of which projects will finish this year
- Allocating staff to specific projects, i.e., estimates of how many total staff will be needed on each project
- Making commitments to internal business partners (based on projects’ estimated availability dates)
- Making commitments to the marketplace (based on estimated release dates)

For anybody who wants to hear both sides of the story, and at the same point of time get some insight into two great minds in the software devlopment industry I would urge you to read (and view) the discussion between Steve McConnel and Ron Jeffries. The articles are sorted from last to first.

- Ron Jeffries: Summing up the discussion (revised)
- Ron Jeffries: Estimation and Steve McConnell (Again)
- Steve McConnel: 17 Theses on Software Estimation
- Ron Jeffries: Continued Discussion with Steve McConnell
- Steve McConnel: #NoEstimates - Response to Ron Jeffries
- Ron Jeffries: Steve McConnell on #NoEstimates
- Steve McConnel: #NoEstimates - Video

Read more…

Wednesday, March 23, 2016

The ScrumMaster checklist and focus

Agile Checklist
In 2007 Michael James wrote the first version of his ScrumMaster Checklist. It is still a very valuable resource for any ScrumMaster. The checklist identifies four areas of focus for a ScrumMaster.

- Team
- Product Owner
- Organization
- Development practices

These focus areas also expose a common ScrumMaster problem: too much focus on the team. The initial focus of a ScrumMaster towards the team(s) is high, but it should decline over time. When the teams are formed, the ScrumMaster spends a lot of effort on educating and coaching the team(s) in self-management and taking on a shared responsibility. Over time, the team(s) rely less on their ScrumMaster as they take on all responsibility by themselves.

The guys from LeSS wrote a great article about the role and focus of a ScrumMaster in a LeSS environment, and how the focus should change over time. I am the opinion it is not any different for a ScrumMaster in any other environment.

Initially, the ScrumMaster focus towards the Product Owner is coaching him in the role. This includes education on how he can best use the Product Backlog, facilitation of his interaction with the team(s), and being there to help him reflect.

The ScrumMaster should also help the Product Owner getting closer to real users and customers. The Product Owner needs feedback from them to validate the direction of the product. It also happens that the Product Owner is the ‘wrong’ Product Owner; then the ScrumMaster should help the organization to find the ‘right’ Product Owner who is close to users and customers.

The focus of the ScrumMaster towards the Product Owner should decrease over time as the Product Owner gets more comfortable with his role within the organization.

The focus on organization is a little counter intuive. Agile adoption require an initial structural change, thus initial organizational focus is high. For example the setup of feature teams. The focus on improving the organization drops once the basic structure is in place. Then it’s the teams’ turn to produce results. The best way to change an organization is by producing results. Why would the organization trust you and your teams if you didn’t show them results and benefit? After this is established the ScrumMaster should take a leading role in further developing the organization as a whole, not just the ScrumMaster's team(s).

As a ScrumMaster, you need to be aware of modern development practices are and help introduce these to the team. In order to deliver quality software every sprint practices like Unit Tests, Test Automation, and Continuous Integration are essential. Agile adoptions often involve large codebases with lots of messy legacy code; applying modern practices on them is challenging. The focus on development practices stays high as it will only become harder and harder to improve the teams even further.

Read more…

Thursday, March 17, 2016

Next generation Scrum? Or just being Agile?

A while ago I read a blog post by Boris Gloger that interested me. It was titled "From Scrum 1.0 to Scrum 3.0". It had a few good points and besides the versioning of Scrum I found myself in agreement with what he wrote.

Today I decided to google a little on Scrum 3.0 and found an article from Sebastian Radics on his Blog "On the Agile Path". He had the opportunity to join a presentation by Boris Gloger talking about Scrum 3.0 and Organization 4.0 at an event organized by Immobilienscout24. His post provides a summary of his notes and insights about some topics presented by Boris.

His summary got me thinking and I decided to add my own notes, comments and insights to his. My additions are all in red.

A little bit on the history of Scrum. Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the New Product Development Game. The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team "tries to go the distance as a unit, passing the ball back and forth".

In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, and were the first to refer to it using the single word scrum.In 1995, Sutherland and Schwaber jointly presented a paper describing the scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as scrum. In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile Software Development with Scrum.

Let's call the version described in this book for arguments sake Scrum 1.0.

Scrum 1.0

- foundation by e.g. Agile Software Development with Scrum (Ken Schwaber)
- basic meeting artifacts, 3 roles (ScrumMaster as management role, Product Owner and team)
- retrospective was not yet part of it
- Backlog idea, but not yet that established
- focus on delivery
- sprint idea – a common way to think about what we would like to deliver together, but breaks in between sprints
- long Excel-lists with tasks and detailed task estimations

What did we learn?

- breaks between sprints don’t make sense
- role of PO was still a business analyst role
- why 30 days and what does it mean – is it calendar days, what about Christmas
- sprint planning and commitments did not work

Scrum 2.0

- roughly since 2004 – driving question, how could it really work?
- breakthrough for retrospectives on the Scrum Gathering in Vienna … shortly thereafter commonly used practice
- more advanced ideas about the sprint planning
- PO has to prepare the backlog and user stories
- PO has to know what she wants
- PO became the single wring able neck
- Sprint review pattern … PO decides if the delivered is right or wrong
- created a difficult situation for the PO
- did the team fail when something did not get delivered (based on Waterfall-like thinking … for sure the team failed))
- followed by the PO shouting on the team

What did we learn?

- PO mega busy
- we created a really stressful environment
- things were not really clear
- but many best practices arose
- requirements were articulated using user stories
- dailies – post it moving sessions
- one can build a huge amount of trash following best practices
- Scrum and the process … Scrum as the Silver Bullet
- great selling argumentation for Scrum
- it worked somehow on methodical level but did not address several problems e.g. scaling
- approach to use Scrum of Scrum
- collocated teams e.g in 2010/11 – huge teams 18, 18 coaches, 18 POs … highly stressful, not that much fun … and the organization killed the initiative shortly after the project was delivered
- heavy meeting load for the PO – Daily, SOS, PO-Daily, Review … does not scale
- architecture … topic commonly shared infrastructure – addressed via communities of practice
- team delegation and architects, but slow and often no decisions leading to the best people leaving the community
- today called guilds
- process, process, process

Scrum 3.0

- ideas collected from the last 2-3 years
- all methods elaborated
- new best practices

Product Owner

- it is not her duty to write stories, it is the team’s responsibility [I fully support the idea that the team should be responsible for creating Product Backlog Items. I am the opinion though that User Stories are used to much, and are many times not the right format for Backlog Items. See for example my articles "Specification by Example in Actuarial Modelling" and "Product Backlog Stories…"]

- team has close contact to the customer … and developers write stories [100% agree, but why is this so hard. At the last Scrum Breakfast Club I asked the questions "why do Scrum teams have no contact to the customer at your project?" and the responses proved that the question to be formulated right, cause in most projects this is not the case.]

- PO is responsible for creating and transporting the product vision … the WHY becomes the central question to answer [Why are we doing this? And why are we doing this NOW? are the two questions that should be answered for any Product Backlog Item. See my article "Why are we actually doing this project?" for some more ideas about this topic.]

- team – includes everyone necessary to really build the product/system [Essential for being agile. See my article "Agile Team Organization" for more ideas about this topic.]

PO should have a basic understanding of the architecture, components and technology of the product in order to communicate effectively with the team.


- major goal: progress [This was always the goal, but somehow got forgotten. The Scrum Guide is even updated accordingly. "The importance of the Daily Scrum as a planning event is reinforced. Too often it is seen as a status event. Every day, the Development Team should understand how it intends to work together as a self‐organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The input to the meeting should be how the team is doing toward meeting the Sprint Goal; the output should be a new or revised plan that optimizes the team’s efforts in meeting the Sprint Goal. To that end, the three questions have been reformulated to emphasize the team over the individual:

o What did I do yesterday that helped the Development Team meet the Sprint Goal?
o What will I do today to help the Development Team meet the Sprint Goal?
o Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?]

- everyone shows their progress on the product instead of moving tickets around [I do not think this always makes sense but I will give it a shot and see what happens.]

- Mob programming – all work TOGETHER and show themselves the results (pairing next level) [Very interesting idea. Hard to explain in a larger company that this could be effective. I have to admit I have no personal experience yet, so this one goes on the list of experiments I have to try once]

- no more PO dailies

- distributed teams – reduce amount of necessary communication through an intelligent architecture with clean interfaces and restructure your organization accordingly [co-location is desirable, but not realistic in the current world, hence dealing with distributed teams is just fact of life.]

- company example – one product one team, teams build that product like they think and its ok if there are differences among products (you can drive some level of standardization using guilds if necessary) [I agree with this partly. You should still keep in mind some things, for example when deciding technology for your product. When your whole organization runs on Oracle DBs and hardly makes sense for you to use MS SQL Server. When you have 30 expert JAVA developers in house and most products being develop din JAVA you might not want to use C#. Most product "differences" are on the UI level and can be greatly reduced by make them look the same. UX should be optimized for the product, so differences between products should be expected and even desired.]

No Meetings

- reviews and dailies are removed or completely changed [This is an option to try in a team that has worked for a while together already, for a newly composed team I would start with doing dailies. To be honest I actually like dailies when you keep in mind that they should focus on progress and impediments and are NOT a status meeting.]

- cancel all regular planned meetings [Agree, except for Sprint Review meetings. In larger companies with a project with some stakeholders in upper management you will need to send an invite rather early when you want them to show up. Keep in mind they are not managing their own calendars…]

- establish communication on different channels e.g. chat [I have learned to like chat again. I despised WhatsApp on my cellphone for private use and was driven nuts by group chats. But for a Scrum team this is a very functional way of communicating.]

- ad hoc session to discuss next steps on your product development [This works when you move more to a Kanban style of working and remove the concept of Sprints. Just continuously work on, and deliver new functionality. This is very high on my experiments to try list.]

- optional meeting attendance [I have implemented this on a few projects already and it can work. Depends on the team and their corporation / communication. But it is worth a shot to try in any project. When it works it improves moral and reduces waste]

- if someone does not attend, it is his duty to get up to date afterwards. It is a shift of responsibility back to the individual

- pair programming – (Manlow Innovation) – that really established pair programming in a tough manner [One easy way to "enforce" pair programming is to allow only one story in progress for each two team members. I have found this to work like a charm and has the nice benefit of focus]

One piece flow

- people just work on one story at a time – all together (e.g. using Mob programming) [Could work, but hard to explain to the people paying for the project. I have added it to my experiments list]

- differences really get transparent

No Estimates

- who still needs story point estimations? [I do not :-)]

- it is enough to count things that get delivered in a given amount of time [Fully agree. Estimations are very rarely useful. For most projects I do I have to make them at the beginning in order to get a budget (see my article "Scrum Enterprise Budgetting") After that they do not help being productive]

- story points were an interesting idea back in 2003, aiming to remove estimation in hours [But that did not really worked out. People starting translating them back into hours and still use velocity as a performance measure of teams.]
- using Kanban one tries to optimize flow and throughput [I am falling more and more in love of the idea of not using Sprints at all anymore and using Kanban style throughput management.]

- reduce backlog size [You can start doing this today by building a filter and only display stories that are "Ready" i.e. discussed with and understood by the whole team. I do this at all my projects cause it helps keeping focus and overview. When you have to much of them your priority is unclear or you have to much Backlog Refinement meetings.]

- PO has to learn to say NO

- best backlog size is 1 [I disagree because I am not convinced about the Mob programming thing yet. I would like to have enough stories so that each pair in a team has something meaningful to do]

- communicate and establish that we do one thing at a time and not more … FOCUS [See above. Focus can be one thing that exists out of multiple Backlog Items]

No releases

- get it live immediately and receive real customer feedback (not management and PO can decide what works for the customer, it the customer who decides)

- user stories are no laws but a way to foster communication [As said before, the 3Cs are essential, but they can be about any Backlog Items, not necessary a story]

- working with releases created delays – lets work on removing these delays [100% agree. Continuous Deployment is the ultimate goal. But it is really hard. Your team needs the skills to do so. See my article "Three must have Technical Competencies for Scrum Teams" for more ideas on this topic]
- embed deployment in the team – DevOps – the team builds it, the team is shipping it

Product development

- no longer with backlogs but using design thinking approaches, hypotheses and data [I disagree here. Cause hypotheses, data and design thinking all result in a Product Backlog Item… something that the team has to build and then will be deployed so that feedback can be collected]

- driven by thinking … how do I get to the needed/right functionality

- design thinking … I don’t really know what to build

- based on assumption, mini prototypes and/or fast and cheap development

- to learn whether we’re moving in the right direction

- learn to think what the user is thinking

- important early link with the real user

- cost estimation? use probability approaches and forecasts based on delivery time and needed scope [See my articles "Scrum Enterprise Budgetting" and "Estimating with Wideband Delphi and Monte Carlo Simulation" for my ideas regarding cost estimations]

- ROI and budget response to the teams – and POs have to take this new responsibility [100% agree. A PO cannot decide on priority when the PO does not own the budget]

- measure ROI increase [this is hard to measure, but starts the rights discussions. Besides this PKI I would measure a few other things as well. See my article "Scrum Project Succes Metrics" for some more KPIs]

Check your level of agility by watching:

- politics in your company – how many discussion are inward focussed (between departments and hierarchies)

- it’s not about self organization – it’s an instrument – but the real goal is that people behave in a way that it is useful for the product to be developed. And therefore its of high importance that it is voluntary.

- the main task for a ScrumMaster – how can I help and guide others to contribute and have fun working on it.

- focus not solely on the process but on the purpose of doing something

Maybe I missed some important points? Please share your thoughts and insights with your highly welcome comment.

Read more…

Wednesday, March 09, 2016

Agile team organization

Most projects I am involved in are of such a size that multiple teams are involved. An even when the project itself consists of one team, many dependencies with other teams/departments exists. In theory this is not an issue but in practice it usually is because how the teams are structured.

Some general patterns that I typically see are:

- Discipline Teams: Programmer Team, UI Designer Team, Tester Team, DBA Team etc.
- Location Teams: Zurich, Bern, Ney York, London etc
- Architectural Layer Teams: GUI, Middle Tier, Database, Infrastructure, etc
- Component Teams: Model Component, Computation Component, Configuration Component etc.

What I unfortunately do not see a lot are so called Feature Teams. A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features one by one (Lairman/Vodde).

The characteristics of a feature team are:

- Long-lived: the team stays together so that they can grow into higher performance; they take on new features over time
- Cross-functional and cross-component
- Ideally, co-located
- Work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
- Composed of generalizing specialists
- in Scrum, typically 7 ± 2 people

Applying modern engineering practices, like continuous integration, is essential when adopting feature teams. Continuous integration facilitates shared code ownership, which is a necessity when multiple teams work at the same time on the same components.

One common misunderstanding of feature teams is that every member of a feature team needs to know the whole system. This is not the case because

- The team as a whole, not each individual member, requires the skills to implement the entire customer-centric feature. These include component knowledge and functional skills such as test, interaction design, or programming. But within the team, people still specialize… preferably in multiple areas.

- Features are not randomly distributed over the feature teams. The current knowledge and skills of a team are factored into the decision of which team works on which features.

Within a feature team organization, when specialization becomes a constraint…learning happens. Moving away from component and discipline teams is a difficult but necessary step for those who want to adopt an agile approach. In Scrum for example, you have a team, a ScrumMaster, and a product owner. These teams work on customer-centric features that are iteratively developed, and in order to do so they should be a feature team.

There are many advantages to organizing multi-team projects into feature teams:

Impact evaluation: At the end of a sprint, a feature team will have built end-to-end functionality, traversing all levels of the technology stack of the application. This maximizes members’ learning about the product design decisions they made (Do users like the functionality as developed?) and about technical design decisions (How well did this implementation approach work for us?)

Waste Reduction: Handing work from one group or individual to another is wasteful. In the case of a component team, there is the risk that too much or too little functionality will have been developed, that the wrong functionality has been developed, that some of the functionality is no longer needed, and so on.

Communication: Because a feature team includes all skills needed to go from idea to running, tested feature, it ensures that the individuals with those skills communicate at least daily.

Risk Mitigation: The work of a component team is valuable only after it has been integrated into the product by a feature team. The effort to integrate the component team’s work must be estimated by the feature team, whether it will occur in the same sprint during which it is developed (as is best) or in a later sprint. Estimating this type of effort is difficult because it requires the feature team to estimate the integration work without knowing the quality of the component.

Customer Focus: Organizing teams around the delivery of features, rather than around architectural elements or technologies, serves as a constant reminder of Scrum’s focus on delivering features in each sprint.

Of course, there will be occasions when creating a component team is still appropriate, for example when a new capability will be used by multiple teams or when the risk of multiple solutions being developed for the same problem is high. Overall, however, the vast majority of teams on a large project should be feature teams.

Read more…