10 things your Scrum team is doing wrong

Scrum is not a silver bullet, and it takes effort and practice to get right. Have you had a challenge getting Scrum working well for your organisation? Here we look at the 10 most common issues found when teams impement Scrum - Do any of these ring a bell?

#1: Your Scrum Master wears another hat

• Perhaps its the name that is the reason why this role is misunderstood? What is it that Scrum Masters do anyway? Unlike ‘Project Manager', ‘Back-end developer’, or 'business analyst’ the name doesn’t really describe the role, so often ‘scrum masters’ wear it as a second hat to ‘Lead developer’, Analysis or other delivery role. And more often, organizations figure its a non-role and anyone can do it - we dont need waste a headcount….

• Actually, the Scrum master is the 'Master of Scrum', and has authority over the Agile processes and practices the team follows. They guide and lead the team to view its delivery, productivity and impediments etc. and to act upon them, thereby improving productivity. This team-level viewpoint is often at odds with down-in-the-deatails view of delivery roles. Expecting one person to hold both these views simultaneously and have the skills to perform them well is unrealistic and will compromise both roles. Better to share a Scrum Master with another team, than make this compromise.

#2: Your Product Owner is not available

• Where is the PO? Why are they so busy as to not attend most of the sprint meetings? POs should spend a lot of time with their stakeholders, but not to the detriment of the team….Is it because they are in constant communication with their management on deciding strategy, the big, up-front plans the checking of details…..?

• Product owners need to be empowered to meet with their stakeholders and make decisions on their own, only taking direction and support from the leadership when needed. They must also have the time to discuss, negotiate and give feedback to their team constantly. So stop with the weekly department strategy meetings, the 1-2-1s with line-managers: They can start attending your backlog refinement and sprint reviews instead.

#3: Your Planning meeting is too short

• At stand-ups, is your team asking about acceptance criteria? are you discovering work as you go along? Do stories get re-estimated during the sprint? Are you having design meetings to go over your backlog items? Do you carry-over work into the next sprint, like, all the time? These syptoms all point to not enough time in planning.

• The output of sprint planning (alongside sprint goal and commitment) is a plan for each story in the sprint backlog - i.e. a list of sub-tasks that the team have agreed will more-than-likely implement the story. Sub-tasks should be less than a day’s effort. The thought process of creating these implementation plans, with the whole team’s input, usually negates the need for those time-consuming extra-scrum meetings listed above, and leads to better forecasting.

• Spending time dealing with an incomplete plan takes much more time and effort than doing it right first time. In short: If your sprint is two weeks, you need at least two hours. Don’t skimp!

#5: You are not breaking your work down enough

• The focus of planning is a moving picture: Your product backlog should predominantly be Epics and Users stories described at a high-level, ready for change and negotiable. Its only when we get to the planning meeting that details are decided and sub-tasks written to implement the stories - and only for those in your sprint backlog.

• User Stories or tasks should be less than a week’s worth of effort, Subtasks less than a day. There are 3 good reasons for this: The though process of planning work at this level of granularity help to have a well-thought out plan that can understand the delivery, uncover dependencies or coordination and avoid problems. Second, during the sprint the team can see daily progress - or not - of their plans to prompt corrective actions. And third, understanding this level of detailed work allows the team to understand itself better, its preferences, impediments, skills, and other ways of working that remain hidden if not broken down enough.

• There are many ways to break down work - see the excellent Richard Laurence’s blog at The Humanizing Work Guide to Splitting User Stories for several techniques.

#6: You don't protect the sprint plan

• Does your team add work to the sprint backlog during the sprint? is anything removed to make space? does anyone raise a hand? does anyone care? If work can be added with no consequence to the sprint, doesn't that put the goal in jeopardy? and if so, why is there no push-back? Will work just be carried over to the next sprint?

• Protecting the sprint means being focused on the work and what the team are delivering. If work must be added, then something must be removed to protect that delivery and by extension, the trust of your stakeholders. Being sloppy on sprint goals, delivery and focus erodes this trust and is very difficult to regain.

#7: You don't have stakeholders at your review

• You are having reviews, aren't you? so who is attending? Is anyone representing customers beyond your PO? if not, then who can review your work? in what way will you check your results and get steer through feedback?

• As a first step, identify your stakeholders. Find the nice ones, the ones whose feedback will be sympathetic and useful, then find the nasty ones. Who needs to be actively engaged to keep them on-side? A great technique here would be Stakeholder Mapping. With this done - hold them close, and keep communicating!

#8: Your Retro is boring!

• Does your retro bring up the same issues time after time? have people stopped attending? have you dropped it completely? I find that much of the time, the issues discussed are the kind that can never be solved, or have a long-term solution only, like “moving to the cloud”, “wait for the next major release” or “hire a new architect”. These solutions are outside the team’s sphere of influence, and are not going to change anytime soon - so find another way to deal with it.

• Instead, make sure you discuss improvements that your team can make - inside the sphere of influence. How can they make their situation better? What teamwork, communications or toolset changes can they make to have an impact - then, have that impact!

• And while your about it, make sure the team is Reporting issues those long-term issues alongside their impediments to the middle management and leadership - they might be able to do something about it, so keep them visible.

#9: You don't follow up retro actions

• Your Retros just sort of end. You’ve found issues, you’ve talked about them. You’ve said “This needs X”, or “We should all do Y !” but nothing is followed up (or only trivial ones)

• The foundation of Agile is inspect and adapt - find improvements to try next time. That is what the retro is explicitly for - it is THE way to be Agile. Without implementing improvements, how will improvements be made? how will the team progress to high-performance?

• So please, after every Retro, plan to have actions and volunteers to implement them. Set these expectations at the beginning of the meeting.

#10: You don't have sprint goals, or they are meaningless

• Our sprint goal is to do the work we planned, right? Get stuff done, whatever the stuff is. Goals of this kind are mostly worthless - why bother with a self-fulfilling goal?

• If this is your team, then be aware, because it is a sign of of having little strategic awareness. You may have good tactics to get stuff done, but to what end? for what purpose is the team working?

• When teams use goals to strategically plan product deliveries, align to OKRs, and the product and organizational goals, your team will be aiming to meet them. Usually it is the lack of empowerment of the PO, or lack of clear product strategy that is stopping this from happening, so for all you Agile Leaders out there, its time to let the team’s decide.

Scrum is easy to understand but to implement is tricky and needs discipline and support. If you would like help with these problems, get in touch with us here at Manmaru wheere we can offer you support and coaching on these issues - tell us here:

The right time and place to use BDD

What’s that smell?

More and more frequently, I see user stories that look like this:

As a User
Given I have accessed the login page
AND I enter my username
AND I enter my password
If my account is valid
AND my password is at least 12-40 characters long and is encrypted AES192
WHEN I press the login button
AND the login credentials have not been rejected more than 3 times
AND the remember me checkbox is ticked
Then I want the website to remember my details
AND log me in
AND create a session cookie
SO that I can log in securely

In this real example, the user story value statement “As a <user>...I want....so that...” is smashed together with BDD’s “given-when-then” scenario, with a smattering of acceptance criteria and other details chucked into a mess of a sentence where the focus and meaning has almost disappeared.  Try saying it out loud!

There is a ‘smell’ here - the smell of blindly following a process, by one author, who doesn’t understand what the value statement is for.  This is in direct opposition to “individual and interactions over processes and tools”

These statements are supposed to give clarity and meaning to anyone involved in the developing the software product, and yet are some of the most indecipherable nonsense around. And worse, they have generated a sub-culture of dodging responsibility as a substitute for thinking - this has become ‘the Agile way’ on how requirements are written, and its dangerous.

The most glaring issues originate with confusion around BDD. ‘Behaviour Driven Development’ has become so misunderstood that its has been twisted into ‘Acceptance criteria-driven test scripting’, very far from what the BDD authors were reaching for.

Dan North originally developed BDD as a method for “The kinds of interaction between the people doing the work to deliver software”. “BDD is actually about the sequence of interactions between the various people on my team.  The stories, scenarios and the code itself is a byproduct of that” Dan North, OOPLSA 2007.

What went wrong?

Problems started when this new interactive approach to product definition  came with a shiny new set of tools - JBehave, Cucumber, Concordion etc. This gave eager Developers and Testers something to grab onto, to champion their expertise -  so of course we must use these tools!  Add into the mix that BDD sounds like TDD (another misunderstood practice) and further confusion abounds.  Everyone has set sail in the BDD ship without knowing how to navigate. This has lead to the badly confused scenarios above, a drive to automate testing rather than discuss features and a shutdown of exploratory thinking of product strategy.

As Mark Winteringham points out in The Deadly sins of BDD Scenarios, when scenarios are written in imperative language “we are focused on the granular steps, actions only” “When we use declarative language, their abstract nature allows us to think about different questions...beyond merely carrying out those steps. An excellent tool for collaboration.”   

But the real criticisms of the current use of BDD are:

1. Smells like waterfall. Here we go again with the big, up-front design in detail.

2. No Conversations.  Scenarios are meant to be discussed, negotiated, agreed, possibly in a 3 Amigos meeting.  Instead, I just write my requirements in this format - job done.

3. Lots of detail = lots of work.  Including lots of detail in the scenario means that has to be reflected in the automation scripts, which cause them to multiply when other details are included.  So detailed scenarios lead to detailed tests.  This fine-grain level, plus the proliferation of edge-cases means you team will be writing those test scripts - in addition to unit test scripts.

4. Difficult to maintain. The explosion of detailed scenarios needs to be managed.  Details are likely to change, so you better have a good way of finding those details across your scripts, their after-effects and their dependencies.

5. Slow test times. When there are a multitude of scripts testing the details my mimicking the user experience, these tests take lots of cpu cycles and time, both in execution and in management (set up, tear down, test data, coordination etc). This can drag on the movement to continuous integration.

So how do we use BDD, and when?

But first why? And the answer is Cynefin.  The Cynefin Framework (ref 4) tells us how to operate in a complex system - where features and requirements must be explored and experimented on in order to find better solutions. BDD is a way to express examples of what a system should do when it is difficult to express requirements in the normal way.  For example, when the domain you are in has an unfamiliar, confusing or even unknown terminology- Dan North’s example (ref 1) is the futures markets, but many exist in the medical, Banking, Engineering, and pretty much all other sectors.  Where ‘normal’ requirements analysis becomes uncertain or impenetrable, using high-level examples is a great way to gain insight into what is needed.  Think about it - do we really need a ‘scenario’ to tell us what login is?

In Summary,  We need BDD when working in the complex space, something that Liz Keogh explains effortlessly in (Ref 3, part 2)

So what are BDD scenarios?

One of Dan North’s principles is "In Agile, we assume we got it wrong", so we need to find possible solutions as early as possible using deliberate discovery skills, for example during a conversation of ‘The 3 Amigos’.  We can help guide these conversations by describing the problem as scenarios, then look for uncertainty, and try things out.

What is a Scenario?  “An example of the entire system in action from the point of view of someone who is using it” (ref 1)

Approach to Scenarios “Having a conversation is more valuable than documenting it, which is more valuable than automating it. (ref 3)”

Scenarios are there to guide the conversation from what the user is trying to achieve to how the system should behave.They should remain at a high-level, written in a declarative manner using the domain language.  They are there to bring clarity - not detail - and also invite alternatives and negotiation for their implementation.  They should also be specific in their description of the example. Following these guidelines, the above story would render better as:

User Story: As a security manager I want customers to login securely so that our data and transactions are safeguarded from hackers.

Scenario: Logon with valid account
GIVEN I type ‘dewart’ into the user ID field
AND I type ‘Password1’ into the password field
WHEN I click the login button
THEN the web session is secured to our security standards

Acceptance criteria:
Validated that the password is at least 12-40 characters long
Validated that the password is encrypted AES192 while stored
Validated that the login credentials have not been rejected more than 3 times
Validated that if the ‘remember me’ checkbox is ticked, the website remembers my details

And yes, this can be automated into a test - but that is not (so much) the point - as the Texan’s say, “thats just gravy”

So If I could sum up when to use BDD:

GIVEN we want to explore and guide the possible behaviour of a complex system
WHEN we discuss the possible actions a system should take in different scenarios
THEN write the Scenarios using declarative statements and discuss

Call to action:  What has been your experience with BDD scenarios - do you find horror stories like mine? Or am I just unlucky?  When do you find them best to use?  Let us know in the comments below:

---

References:

1. Dan North: Interview with Dan North on Behaviour-Driven Development” 2007

2. Mark Winteringham: “The Deadly sins of BDD Scenarios”, YouTube 2017

3. Liz Keogh: “10 years of doing Behaviour Driven Development all wrong ” Parts 1 & 2, YouTube

4. Dave Snowdon: Introduction to the Cynefin Framework, Cognitive Edge, http://cognitive-edge.com/videos/cynefin-framework-introduction/

Scrum Masters: How do you deal with carry-over?

On a recent project, I was conferring with another experienced Scrum Master when we discovered a small but significant difference between our thinking around how to manage carry-over stories.  I’d like to ask this audience – what is your preferred method – and why?

The Scrum guide tells us that teams must deliver “potentially shippable product increments” each sprint – but what happens when they don’t?  What should a Scrum Master do - in terms of planning - when a story has been worked on, but not completed?

Usually the story is still at a high priority and so is ‘carried-over’ to the next sprint – simple right? …but one question – what is the estimate for that story? 

When planning a sprint, the team should look to their capacity and select the priority stories that can fill that capacity. But what happens when a carry-over story is brought from a previous sprint? It turns out my friend and I had different methods. Let me illustrate these methods and their implications:

Method 1: The estimate is the same as before, no matter how much work was actually done in the previous sprint – e.g. if it began as 8 story points (sp), the estimate remains 8.

Pros: don’t need to re-estimate, the product backlog doesn’t change – easy!
Cons: This doesn’t reflect reality i.e the velocity figures skewed. The team might not reflect on estimates, and their estimates may become devalued.

As the carry-over story will be completed quickly (only 1sp left), The team then can either
a)    plan more stories in the planning meeting (in spite of velocity)
b)    Wait until these stories are done and plan more at the end of the sprint
c)    Do nothing and let the carry over story cover a gap in their velocity this sprint.

While this seems the easier method, everyone has to remember that the 8sp was a carry over, and adjust velocities and release plans.  If you are using Jira or another tool, then this can be a pain each time you show a report etc.  There is also a danger that estimates themselves become devalued, as they don’t change when the story is replanned.  These are less than optimum behaviours here, which is why I don’t prefer this method (although I have used it).

Method 2: Re-estimate the work remaining e.g. 1sp – and use that to plan the next sprint.

Pros: accurate velocity (both average & individual sprints), burndown charts etc. reflect reality.

Cons: The team has to re-estimate what is left. The Product Backlog and release plans are updated.

This is the method I use as it reflects reality and keeps everything visible and gives an easy start to a conversation about the story, its issues, and its plan.  However, when I do use it, the team often feel they have ‘lost’ points: they worked on an 8sp story, but now only get 1sp. This is true – and it’s also fair and good discipline.  They may have worked on the story, but it is not delivered, and that means no points!

The Role of Scrum Master

One of the Scrum Master’s responsibilities for the team is to ensure Scrum is enacted well, and that the team is improving.  That relies on having transparency of both good and bad stuff that happens.  When a team has not performed as expected, reflecting on carry-over work is the opportunity to review their estimates - to uncover any issues with a view to improving them and dealing with any issues. 

The team may not like the fact that their work has ‘lost points’, but then that’s what non-delivery is – the team should be mature enough to account for their work and be held responsible.  This must not be seen as blaming, but of being responsible. After all, the team is given responsibility for the estimates and for carrying out the work.  If something goes wrong, it needs to be highlighted and addressed by the team.

These are the methods my friend and I discussed, but what does the wider Audience prefer, and why?  Are there other options?  I’d love to hear your comments – or click ‘like’ if you were interested in this issue. 

Agile Team Start-up

A few weeks ago, a junior Scrum Master asked me for a check-list of tasks for starting a new Agile project.  I'm not a fan of check-lists, but this topic seemed appropriate, and useful. It also is a good one to ask for feedback and additions - what would you add to this?

My starting point would be to imagine what a Scrum Master should ask or do when beginning a new, long-term engagement (at least 6 months) at a client location, with a team who don't know each other or Agile methods!  Here goes....

1.Basic Environment

• What is the security, building pass, access times policies of the client location?
• What is the Desk policy? What furniture is available - can you bring in more?
• Can you use the client’s printers, scanners, video conference, rooms, stationary?
• Network, Wi-Fi, Servers, databases infrastructure: Can you use the client’s or bring your own? Who supports them?

2.Team Environment

• Can the team sit together? Who else is around? Can you control how hot/cold, bright/dark, noisy it is?
• What can be used as a physical Scrum board? Can you stick stuff on the walls?
• Do you have a TV or projector for reviews, etc.
• Find a Talk token, Ÿget a notice board, hang posters, calendars, etc.

3.The Team

Assuming the team doesn’t know each other, it is important to create good social relationships first to then build them as a team with a shared understanding, culture and skill base to prepare for development work.  Try to get them from ‘forming’, through ‘storming’ to ‘performing’ as easily and quickly as possible…

• Use team games for Introductions, get to know each other, team socializing
• What snacks, food, music, dress code is acceptable? Not everyone welcomes donuts!
• Collect and publish team contact info, locations (virtual and physical)
• Agree and publish the team’s availability – including PO & SM
• Agree working agreements
• What are the core working hours of the team?
• How to deal with holiday, illness, and absence requests, etc.
• Coaching ‐”Shu Ha Ri”
• This is a good time to offer some Agile coaching to the team to raise their awareness of their Agile journey, for example, through “Shu Ha Ri”.  This helps sets the culture of realistic expectations, improvements, coaching…
• Training. This is also a good time to organize some basic / refresher training in the following topics to bring everyone to the same understanding.
• How to behave as an “Excellent team”
• Scrum
• Effective Story breakdown techniques
• What Tools will we use e.g. for CI, Jira, etc.
• Values: Now the team is forming, what values will it embody?
• E.g. Commitment, Focus, Openness, Respect, Courage?
• Pick a Team name, create some culture
• On-boarding. When new team members join, how will they be brought up to speed? Can the training, teams values be documented? Use a buddy system?
• Future Retro: Now the team has formed, get them to start looking forward to the work ahead in terms of outcomes. A nice way to do this is to hold a retrospective looking forward to the future, asking “What would you like to celebrate at the end of the project?” The focus should be not only on what they deliver, but how the team delivers, how they behave when issues come along, what the client/users/managers will say about them. It also helps practice their first retro in a safe environment.

• Practice review – PO and team: Similar to the future retro, hold a practice review to find out how to hold effective reviews.  Important stakeholders should be attending, so make it as good as it can be.  How are the team’s presenting skills? What room and setup is best?  What progress indicators will the team show?  The review subject can be all the activities the team has done so far. 

4.Ready to Sprint

After building a functioning, informed team, the final stage is to get ready to Sprint, to identify the specifics of Scrum and the vision and existing backlog of the project. These should be carried out by the team collaboratively:

• Choose an Estimation scale (e.g. Fibonacci) and  Identify stories as references
• Write the Definitions of Ready and Done, and publish them
• Choose a Sprint length and schedule, including:
• Sprint Start day
• Planning location
• Daily stand-up time and place
• Review, retro
• Backlog refinement
• Product Vision, Features, Non-functional requirements.  This is where the Product Owner can now step forward and introduce the team to the specifics of the product, presenting the business situation, current backlog, risks etc.
• Milestones, phases, release plan: How has the product schedule been planned – e.g. Discovery, Alpha, Beta?
• What Metrics will the team publish? What is their audience, their ownership and frequency?

Round Up:

One of the key parts to a Scrum Master’s role is to guide the team’s success and productivity, and the most important part of this is when the members first come together.  Once these points have been met, the team will be in a great place to start development and negotiate the challenges during the lifetime of the project.

But is there anything more that should be included?  What would you add or change for your teams? please add your comments below.

Are you Theory X or Theory Y?

The Agile Manifesto’s most important guidance is its first line:

Individuals and Interactions over Processes and Tools

To get the best from our individuals, the 5

th

of the Agile principles is:

Build projects around Motivated people

Motivation is important -  it releases energy and creativity to gain high performance. 

Of course the question is, how are people motivated? And thinking even before that, what do people need to be functional?

Self-Actualization

Agile looks to the work of American psychologist Abraham Maslow in the 1940’s “The Theory of Human Motivation”. Maslow studied exemplary people, such as Einstein, as to how they were motivated, and formulated his now well-known pyramid of needs:

The cornerstone of Maslow’s theory is that people have an innate impetus to continually develop and succeed, and that they naturally move to self-actualization only once all supporting “deficient” needs are met. 

The fourth level, Esteem, means attaining self-esteem and self-confidence through competence or excellence in skills, abilities and achievements. Having self-esteem leads to a sense of contribution, of achievement and recognition. When esteem level is met, people will discover their full potential and become self-actualized. They can provide support and guidance to others.

Management’s Attitude determines Motivation

Maslow’s theory leads to, among others, Douglas McGregor’s 1960 book “The Human Side of Enterprise” in which he proposes that the manner of management’s interaction with employees is their primary motivator.  McGregor posits there are only two ways to motivate individuals based on Maslows lower and higher needs, which he named

Theory X

and

Theory Y

.

Management that uses

Theory X

treat employees as:

• They are Lazy and dislike work
• Require close supervision and control
• Lack ambition without incentives
• Avoid responsibility
• Only work through threats and punishment
• Have personal goals that go against organization goals
• Their creativity and imagination are not used for work

Summary

: Focus on methods of control and punishment to drive productivity.

In Contrast,

Theory Y

managers see employees as:

• Ambitious
• Self-motivated and self-controlled
• Treat work as a natural and normal part of life
• Initiate their own learning
• Accept responsibility and commit to organization objectives
• Appreciate and respond to recognition and encouragement
• Enjoy solving problems
• Are demotivated when their talents are not used

Summary

: focus on creating the right conditions for employees to be self-directed

McGregor's conclusion is that management using Theory Y leads to better outcomes and productivity for the individual and organization.

But so much for the Theories – what actually works?  

Well, when it comes to culture, generally management get what they expect, and leaders set the example and standards for behavior in their organizations – which theory should be used for the IT industry?

We saw that the Agile Manifesto rates people to the highest position. That’s because modern software development is  team is a creative, collaborative activity, high performing teams, leadership and responsibility at all levels

Transitioning to Agile means a large and complex cultural change. Theory Y enables this, while Theory X blocks. 

So Agile leaders must adopt Theory Y management style

Conclusion:

In 2010, Dan Pink’s Drive highlighted that there are less and less job roles where Theory X would be appropriate, whereas theory Y has become a significant advantage for companies

The factors for highly motivated people are:

• Autonomy: people desire to direct their own lives. Gain control over their work
• Mastery: to become better. Need and environment where learning is encouraged and mistakes are tolerated
• Purpose: a natural desire to be part of something bigger than themselves 

So ask yourself, are you theory X, or Theory Y?

A Scrum Weakness: The Product Owner Role

The principles and practices behind Agile and Scrum are demonstrably better in terms of productivity, quality and job satisfaction. In the past 10 years in the UK, we have seen the Agile movement go from a crazy idea in the depths of Shoreditch to the defacto method of choice for government IT initiatives.

But Scrum is not perfect; it has weaknesses that all its practitioners should be aware of.  In this short series of blog posts, I will aim to discuss these weaknesses (as I see them) and explore their mitigation.

The Product Owner Role

The Product Owner is one of the key members of the scrum team and a critical success factor to any Agile development project but the Scrum Guide gives barely half a page to describe the role. "

The Product Owner is responsible for maximizing the value of the product and the work of the development team. How this is done may vary widely across the organization

"

While the description is terse, it is powerful in what it 

does not

say. Its guidance: "

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the product backlog...

"

But here is where I perceive the weakness: The Product Owner role is key, but in reality it is seldom possible to find

one

individual who can fulfill the role and be available to the team full time (and it is a full time role). As Product Owner, their duties include:

• Communicate product vision and mission
• Continually manage the backlog
• Manage stakeholders at all levels
• Explore and Discuss solutions with the development team
• Attend planning, stand-ups and review meetings
• and a whole lot more

In practical terms, projects need to find solutions that allows the product owner to perform well with limited availability, and when projects scale to medium and large sizes. Here are my alternatives:

Solution 1: The (mostly) unavailable Product Owner

Sometimes it is obvious who in an organization should be the product owner - but very often that person has a day job that they cant (or wont) delegate, even temporarily. The project should appoint a

proxy

product owner to share the role by taking on the day-to-day tactical effort, with the final strategic and authority staying with the Senior Product Owner. 

Solution 2: Product Owner for multiple teams

When a project is of medium size (3 to 5 teams), the Product owner role can be shared between the teams - that is one product owner manages one backlog from which the teams select their sprint backlogs. Depending in the type of project and skill of the PO, this can be managed well. The main drawback is the workload of the PO is taken up by several planning meetings and reviews each sprint. A good idea here is to arrange the backlog into Epics which are assigned to the teams.

Solution 3: Scaled Product Ownership

For large projects, One product owner can no longer service all the teams, and so must delegate to other product owners. This is best done along epics to allow the minimum of dependencies and context changes for Product owners and their teams. Notice that the pattern of a single authority for a product owner is maintained - we don't create a committee of product owners.

NB:

There patterns can be used in combinations!

Conclusion:

Scrum and Agile lore has grown up quickly to support people to become good Scrum teams - developers and managers know about stand-ups, self-organizing, planning poker etc, but there is little common practice to help with the critical role of the Product Owner. To help with your unique situation, use the principles in the scrum guide to better organize your product owners.

I have used these patterns to good effect and hope they are useful in your projects.

How can we manage NFRs in an Agile project?

Non-functional requirements can cover a wide range of context areas and operating restrictions for delivering software systems, including:

• Performance
• Security
• Usability
• Accessibility 
• Scalability

Representatives of these context areas are stakeholders in the success of the product and should be treated in the same way as business process owners in determining the content of an Agile project’s product backlog.

Non-functional Stakeholders may include, but not limited to, Systems Architects, Security directors, Marketing, Database managers, Support teams in addition to customers and users of the product. These stakeholders should to have their requirements identified and captured by the Product Owner for inclusion in the product backlog.

However, non-functional requirements, once identified, fall into two distinct types: NFR stories and NFR Standards.

• NFR stories are very similar to functional requirements in defining how a particular function should behave. They are independent of other stories. E.g. “Passwords must be at least characters and include at least one punctuation symbol”
• NFR Standards set a standard for the behaviour of many parts of the product. They are not independent but must be included into other stories. E.g. “All data access to the accounts database must be audited”, “All web pages must load within 2 seconds”, “All web pages must conform to W3C’s WCAG 2.0 standard”

Standard NFRs cannot be implemented in isolation. Rather they are rules by which other stories must follow.  Typically in Agile methodologies, they are captured as acceptance criteria and integrated into functional requirements and their design. The team’s definition of done can also be used to insure NFRs are met, for example, by determining that all stories must have support documentation written before being accepted as complete. Backlog management tools, such as Atlassian Jira, have several features that can support NFR management in this way.

The Agile approach promotes the idea of testing as early as possible in the development process, and crucially, this can be applied to NFRs also.  Once standard NFRs have been identified to a useful detail (not necessarily finalized), functionality can be tested for compliance with NFRs while it is in development.  In modern development practices, continuous integration systems can ensure the delivered product increments, even early in development, can be repeatedly tested against the defined NFRs.  Any functions that do not meet the NFRs will be identified as early as possible. The tests and their results can be made visible to those stakeholders who defined them as well as the team developing the product.

This approach of capturing and testing NFRs early has many obvious advantages and there are several important steps to implement this model.

1. The Product Owner and team need visibility of NFRs as early as possible, ideally before development begins. 
2. SMEs and stakeholders must be identified who can be responsible for defining NFRs.
3. Suitable environments, data, test tools etc. must be available to allow any specific testing that is required – for example performance test environment.

We don't do "pure" Scrum here

"We don't do 'pure' Scrum here"

Unfortunately, I have heard this all too often in recent weeks while setting up a new scrum team.  Other parts of the organization are having good and long term successes with scrum, but a different team manager has shown some resistance.

While reading Richard Hundhausen's book "Professional Scrum Development with Microsoft Visual Studio 2012" I found a great analogy for just this attitude:

"You can think of Scrum as being like chess.  Both have rules.  For example, Scrum doesn't allow two Product Owners just as chess doesn't allow [a player to have] two kings.  When you play chess, it is expected that you will play by the rules.  If you don't, you are not playing chess.

It is the same with Scrum. Another way to think about it is that both scrum and chess do not fail or succeed. Only the players fail or succeed.  Those who keep playing by the rules will eventually improve, though it may take a long time to master the game."

and those who do not play by the rules will never master the game.  and in fact are playing a flawed game, at best an untried, patchwork game of rules that are cherry-picked with no evidence or experience of their effectiveness.

in short, there is no "pure" Scrum.  You either Scrum, or you do not.

The Scrum Master

Recently, I have been enjoying reading "Professional Scrum Development with Microsoft Visual Studio 2012" by Richard Hundhausen.

One important thing that he reminded me of, about being a scrum master, was the servant leader attitude, eloquently encompassed by the words of Lao Tzu in the Tao Te Ching:

"When the master governs, the people are hardly aware that he exists.  Next best is a leader who is loved. Next is one who is feared. The worst is one who is despised.  If you don't trust people, you make them untrustworthy. The master doesn't talk, he acts. When his work is done, the people say "Amazing, we did it, all by ourselves!"

How Agile sets up teams to be Excellent

Agile is an excellent framework for organizing a team to produce work. But it says very little on how to make that team excellent at what they do. And that is one of Agile’s strengths – it allows a team to find its own way to excellence without imposing rules.

Actually, Agile says *almost* nothing – but it does say this:

-      The best architectures, requirements, and designs emerge from self-organizing teams

-      Agile processes promote sustainable development.

-      Business people and developers must work together daily throughout the project

-      At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

NB: taken from the Agile principles

These principles are still somewhat vague: we have to look at Agile Methodologies, like Scrum, to see how these can be done.  Scrum introduces the Scrum Master with guidelines to promote sustainability, daily working, and reflection in retrospectives.  But the Scrum Master is a servant-leader to the team, and from here Scrum is silent on how to ensure the team is behaving as an excellent team.  Or rather, Scrum, and Agile as a whole, leave the door open for excellence to take hold.

Excellence 

Here excellence is the art of doing things easily, even if they are difficult. It’s maximizing the amount of work NOT done, when you can reach your goals with the minimum of effort, stress, complication. This could have been taken straight from the book of Lean, Occam’s razor - climbers know this as "flow".

Many examples of excellent teams are all around us: A medical team performing open-heart surgery, fire-fighters, an IT support desk, Air-traffic controllers.  In sport: an F1 pit team, a yacht crew, and of course, a rugby scrum. Even in the animal kingdom you can find Wolves, whales, bees and ants whose teamwork is excellent.

Excellent teams are recognized as being excellent by the following characteristics

-      They have a positive outlook with drive and purpose

-      They Communicate well, are Friendly, and even have Fun!

-      They are Supportive, they Share and Learn together

-      They are inclusive, they Trust and Respect each other, are Open and Honest with each other

How then does a team gain these characteristics?

Firstly through awareness: Be aware of when you are excellent, as an individual and as a team. Notice how you get things done, when work is easy, when the team ‘Gels’, or when it delivers. Don’t focus on the negatives – this is practicing to fail. Better to enhance the positive and use the ripple effect to raise all round ability.

Next is buy-in.  Ask the team how they think an excellent team behaves, how work should be done, what it would be like to work in an excellent team. Ask them what actions they could take to encourage that behaviour. Since it comes from the team itself, they will be more receptive to start acting this way.

Ask them what the benefits of excellent teams are? to the team itself, their department, the organization, their customers. The potential alone can be a great motivation.

Finally, make time for the team to update the issues in retrospectives and other discussions, issues such as obstacles to excellence, how to give each other support, and how to build on current successes into areas still below par.

These concepts and tools can easily be combined with Agile methodologies while still preserving the responsibility and synchronicity of the team, and also helping them on the way to discover their own excellence.

This blog was inspired after attending the Technical Excellence course from Meta.  Many thanks to Jo and Di for their insight and support.

When to estimate in Story Points and when in Hours?

Yes, you do need to estimate twice, but at different times and for different reasons: 

Stories should be estimated in story points as soon as they are found. As soon as the PO adds them to the Product Backlog, they should be given to the team for estimating. This can be done in a an ad-hoc way e.g. after daily stand up, or at a regular story-pointing workshop. Doing this allows the PO (and everyone) visibility on the total size of backlog, and allows effective release planning. This also allows the team some visibility of future stories and give input to the PO on options, issues and possible designs. 

So that means in sprint planning, the PO and the team can know pretty accurately what stories will be in the sprint, based on their previous velocity. Planning is split into two parts. First the PO presents the next priority stories, the team discusses them and validates the story point estimates. They do this until they have enough to stories in the sprint. This is the Sprint Backlog. 

The Second half of the meeting is about taking the Sprint Backlog stories and breaking then down into tasks for the team to carry out. Each task should be small so as to be easily understood and carried out. They should also be estimated in (ideal) hours. This has several uses: 
1. Tasks shouldn't be larger than 12 hours (my measure). This keeps tasks small and simple and will highlight problems quickly 
2. It gets the team really thinking about how they will implement the task 
3. When the team starts the task, they know the time it should take and can raise an issue if they cant meet it. 

And of course the team can get another measure of workload against capacity using the total number of hours available to the team, versus the total number of hours for tasks. 

So both types of estimates are necessary for different reasons, but doing both in planning is too late for release planning, and makes the planning meeting very long.

Blog Disclaimer, Comments and E-Mail Policy

This is a personal blog. The views and opinions expressed here represent my own and not those of the people, institutions or organizations that I may or may not be related with unless stated explicitly.

Also, my thoughts and opinions change from time to time as I come to learn more and develop my understanding about the things and issues that I am blogging about. This blog just provides a snapshot of the knowledge, views, and opinions that I hold at a particular point of time and these might most probably change over a period of time. I reserve the right to evolve my knowledge, thoughts, and viewpoints over time and to change them without assigning any reason.

My blog includes links to other sites/blogs operated by third parties. These are provided as a means of convenient access to you to the information/opinion contained therein. I am in no way responsible for the content of any other sites or any products or services that may be offered through other sites.


Comments and E-Mail Policy:
Comments are welcome. However, note that, tasteless and insulting comments may be deleted. Any personal remarks and attacks may be deleted. The same holds true for off-topic comments. Any comments that reek of link spam or marketing messages WILL be deleted.
I am not responsible for the content in comments other than those made by me, or in blogs or other online content that I may link to.

E-mails are welcome and you may write to me at: donaldewart[AT]yahoo[DOT]com.

Please note that I may not be able to reply to all comments and email.

Vertical: the Agile Approach to feature break-downs in a cross-functional team

Its vertical, not horizontal

Very often, the way that requirements - usually described as stories or features - are broken into tasks is along a horizontal paradigm.  But in an agile context, this is the wrong way to promote flexibility, efficiency and teamwork- in short, agility.

by horizontal, I mean in the sense of layers of an application, an architecture that works in separating the presentation, business logic and data handling parts of applications.  But should you create a breakdown of a story into tasks along these layers?
For example, a story "as a customer, I want to register on the website to gain access to personalized services"  registration data might include name, address, phone numbers, email address, passwords, marketing preferences, etc. Breaking the story horizontally would get the following:

1. write page HTML
2. write JavaScript form validation
3. write business level logic
4. write database queries
5. Write test cases
6. execute tests

 The problem is, we have just broken this down in accordance with waterfall.  You cant start working on the validation, before the HTML, and you cant finish the business layer until the database work is complete.  But worse,   you must complete the first four tasks before doing any testing.  So by breaking this along layers we have introduced a mini waterfall.  If each story is treated in the same way, this will lead to terrible issues with dependencies, throughput and team "silos"
This is a situation that can often happen, because it "seems natural" to do it, and is what developers and testers can easily identify with.  However, this is a trap.

Instead, stories should be broken down vertically!

A vertical breakdown is where tasks include all necessary layers of the application to complete a tiny peice of functionality, including testing (and any other phase).These tiny pieces are worked on and delivered by several members of the team at once - i.e. when the designer is building the html, the developer can also code the business logic, and the tester can write test cases.  So a vertical breakdown might look like this:

1. register name
2. lookup address
3. validate email address and password
4. save marketing data

here are the advantages:

• The team can really start working together, rather than just working on bits of the same thing - no more silos
• The team can now start on the first tasks together - designer, coder, tester. 
• These tasks are small, short-lived so they can soon be into the test phase, shortening the build-test cycle.
• if delays in the sprint happen (i.e. due to underestimation, sickness, priorities) work can stop on the story after any of these tasks and the work done until now is still deliverable.

 It can be a difficult change to a team's way-of-working, as they may have to go against years of training and thinkng in this way, but not doing so will doom the team to stay at a low level of agility and efficiency. But it ca also be a sig of a team;s maturity that they can start working together on the verticals.

Can the wrong tools stop you being agile?

One of the Agile manifesto's preferences is for people and collaboration over tools and processes.  For example, having a 2 minute face-to-face conversation is preferred over sending an email.  This is an admirable foundation for the philosophy, but what happens if the environment, technology or tools you must use on a project get in the way of collaborating and being agile?

My current project is customizing a Siebel installation as the organization's CRM solution, and so we have to deal with Siebel's technology.  I have to admit i have never worked with this technology stack before, and so I am relying on the solution architect, team leaders etc for their views on this, which I respect.

The issue comes when it is time to deliver new code to the test environment. Development and unit testing happens in a separate dev environment, then released to the SIT testing environment for system testing. This is the first step in the delivery chain, so each release to SIT becomes part of a collated release to UAT, etc.

Releases can take the form of an SRF, a Repository update, Static data, Workflows, etc.  The problem is that these releases are time consuming and have to be made under a release management process, which involves two other teams (release management, environments) and creating interim documentation (release notes). Because of this, releases cannot be ad-hoc or flexible, and have to be scheduled. This was exacerbated by the release and environment teams being unwilling to perform more than 2 releases per week.

Unfortunately, the team has morphed this into the need for a release plan - scheduling to finish user stories for a certain release date - and so a lot of planning day is consumed by trying to fit user stories into the release schedule so that a tester has enough time to test it.  And what does that look like - mini waterfalls in a sprint!

This has some obvious (to me) drawbacks, in that a missed release date could delay a user story by two days! even for a 2 minute bug fix, so quick turns around times to improve through feedback were non-existent.

In terms of Scrum, it meant that the team were always focused on delivering to the release plan, rather than having the flexibility to deliver when ready (they were even admonished for delivering a story early, as it was not in the release plan!).  Also, since no work could be delivered after the last release, there was a premature end to the sprint which increased the likely hood of stories 'carrying over' to the next sprint, against agile principles. It was estimated that around 10% of capacity was wasted because of waiting time or lost time.

Finally, I also had the impression that some of the team, including the release manager, were deliberately using this as an excuse not to be agile as they didn't want to change.

Unfortunately, in dealing with this situation, I had to wait until the release manager was replaced to get any movement in this area.  When that happened, I immediately went to daily releases - which although not the ideal, helped a lot. 

It meant that I could downplay the importance of the release schedule, and so get back to a more flexible approach to taking on and delivering work, and it meant that we could have releases up to the end of the sprint, so using all available capacity.  I would have preferred to have dropped the idea of a release schedule completely, but this bit of team culture was ingrained pretty deep and the teams elected to keep it.  Our new release manager also helped a lot, as her whole approach was one of helping to deliver, and being flexible but controlled.

The ideal situation of continuous integration is not always possible: The limitations of older technologies, together with old-style ways of working, can severely impede a team from realizing its full agile potential.  But by approximating to CI, and having the will to be flexible, can improve the situation - we were able to reclaim the 10% capacity, and greatly improve the pressure on testing.

Team Culture: difficult to change

I find that one of the most difficult aspects of change a team may have to undergo is one of culture.

Changing the membership, meeting times, workload, locations etc of a team, its relatively easy to get buy-in, as long as you give good reasons and gain consensus.  But there are other aspects of moving a team to an agile way of working that call for much deeper and controversial solutions.

Many teams (including my current ones) on their first agile project still have old-style tendencies that hinder best performance and becoming fully agile.  For example, even within the same team, there can be an "Us and Them" attitude between developers and testers, and at times with POs also.  While these are obvious divisions, this is in the context of traditional management methods which set up these divisions for their own convenience.  But this can be a continuous source or argument, shirking of responsibility and, frankly, arse-covering which all detract from productivity.

To be fair to my teams, the culture of the project did not start with Agile - in the beginning it was a traditional, quasi-waterfall project with design, 3x development and test teams, all with team leaders and managers in the usual hierarchy.  This has been a difficult culture to change: we still need the people who are the team leaders, even if their role has diminished significantly, but this preserves the divisions between them.

One of the central tenets of Agile is its focus on teams, teamwork, and working together towards a goal, and so members need the space to be flexible and adventurous in working outside their comfort zone role when needed.


One example here is when a team realized they didn't have enough test resource to test all the stories developed by the developers.  When given this problem, the team mulled over the suggestion of developers testing each others code, with a caveat that a tester would still do final testing.  Most of the developers were ready to do this, but when pushed, the testers - and test manager -  somehow managed to find enough time to do the testing after all (by working weekends!).

Another example is within the test team themselves - when none of the Siebel tester's in a team would test a Data migration story because "they don't do that"

A true cross-functional team would allow this to happen - in a controlled and visible way so as to maintain quality - but also to enhance productivity without using more hours.  But I felt that while the old divisions remain, Agile's goal of super-productivity can only be approximated.

To help solve these problems, or to try to break the divisions can call for difficult decisions, such as the obvious one of removing the team leaders - but this is often not possible or popular!  Better to engender a new culture of sharing, team-ownership and safety to allow team members to be adventurous.  This could be done through workshops where testers show developers how they test, and vice-versa, and inviting testers to develop some stories in line with their ability (Testers are often good developers too).  Not only does this encourage all the good things of agile teams, but supplies a form of training and teamwork not possible in traditional methods.   

The Team in The Programme

Sept 2010:

As I join The Programme, there was still 18 months left to go - 15 for development and 3 for the last rollout.  The team structure is as follows:

• 3 teams of cross skilled developers, testers, and BAs - team sizes about 10 in each
• Most developers are from the same consultancy, they are a mix of Siebel, OBI and Data migration developers - each discipline has a team leader. There are around 14 devs in London, 3 in Mumbai
• All testers are independent contractors, lead by a test team lead (who doesn't test)
• BAs are mostly contractors, some permanent employees too.

There are around 10 BAs, lead by a team leader.  So three BAs in each team acting as proxy product owners. Interstingly, the "BA team" is using Scrum to organize their work, so they have a separate stand-up each day to synchronize on the analysis of the problem domain.  While this is outside of my scope, I will find out more about this - Scrum applied to analysis.

Other people on the programme: Solution Architect, Programme Manager, Director, Infrastructure team, Support team.

Parameters of content

In starting to write this blog., I first asked permission from my department managers, line managers and programme managers for the kind of content that I should conform to.  Mostly they were very open to the idea, and were happy for me to do this - but in an anonymized way - so names are changed to protect the innocent.

I dont think this matters, and will have little impact on content, as I intend only to document, explain and review the decisions of the programme in terms of Agile Methodology

Start of a new blog

This is the first entry in this blog, so i should eplain what I am doing here.  This space is for me to note, remember and share the experiences, activities and lessons learned that I encounter in my role as a Scrum Master and Agile Evangelist.

I will try to bring this up to date with my experiences so far from the past 3 years, but also add to this with my current role.

While this is predominanlty for my own benefit, please feel free to review and add your own comments and suggestions, and I will try to answer any questions too.