Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.

Some of them were:

• Staying late in office to address a client request?
• Responding to project emails at late night..
• Rewarding testers on number of bugs found and more.

And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.

“You Will Get What You Measure(or Reward)!”

I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.

Definitely, we all have numerous such incidents to share.  How can we design a reward system to get team level behaviour more and less of individual heroics?

There is no greater de-motivator than a reward system which is perceived to be unfair. It doesn’t matter if the system is fair or not, if there is a perception of unfairness, then those who think that they have been treated unfairly will rapidly lose motivation.

Great products are developed through collaborative efforts of many people. So in a development environment, individual rewards will inevitably leave overlooked people feeling that they have been treated unfairly. Moreover, individual rewards fosters competition in an environment where co-operation is essential for success.

Conventional wisdom says that people should be rewarded based on the results that are under their control.  However, information sharing and co-operation are essential, rewards must be based on span of influence rather than his or her span of control.

For example instead of rewarding testers on number of defects found, but rather developers and testers should be measured on team’s ability to create defect-free code. Instead of rewarding developers with technical success of their efforts; whole team should be rewarded based on business success of it efforts.

                                        Team behaviours over individual heroics

                                 Building defect-free code over finding bugs

                                  Accepted stories over delivering stories

                                    Business success over technical success

Building collaborative team is the corner stone of hyper-productive agile teams. Hence middle and senior management has to be extra cautious in their Agile Transformation approach. Implementing scrum with conventional wisdom metrics will not get what we want – A Hyper-Productive Agile Team.

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today.

Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be  done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.

Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.

1. Agile Estimation: 9 Reasons Why You Should Use Story Points
2. Agile Estimation: 8 Steps to Successful Story Point Estimation

Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.

Story point being a coarse grained or rough estimation technique, it helps in long term planning like release planning. Product Owner need not wait for detailed estimates from team to do his release/roadmap planning. Using velocity to do this planning keeps the planning real and honest as it is derived from team data.

We use relative sizing estimation always in our personal lives. Go to a restaurant you order a small coke or large plate of salad.

One the other hand, time based estimation is fine grained. When it comes to sprint/task level, you go for time based estimates for tasks as you have the maximum information/knowledge NOW to make better precise estimates. Deferring finer decision making till LRM(last responsible moment) leads to better agility and predictability. - Focus on details over time as you see in the picture below.

I encourage new teams to estimate tasks in hours for two reasons:

1. To know when you’ve reached sprint capacity
2. Helps in getting a better understanding of the stories when you break in tasks and estimate it

I ask teams to do daily re-estimation of the tasks they are working on, which is just a gut feel from task owner of how much time is remaining for each task in progress. Completed tasks are automatically zeroed and not started tasks are left as is with original estimates which was done in sprint planning meeting. I have found this to be the most accurate and useful way of tracking sprint hour burn-down. This level of tracking helps team to self-organise around sprint goals and commitment.

Over time, teams get better in delivering what they forecasted and seeing success every sprint. Task estimation should no longer be necessary as the team will gain a more stable velocity (making capacity planning less/not needed). The team eventually should be able to rely almost entirely on velocity and gut feel for sprint planning assuming you keep the team constant going forward. Also the team will gain better business domain knowledge and a good understanding of the writing style of the PO (making the second point less necessary).

The team have the right to decide to have tasks estimated or not and they should continuously improve their techniques to make them less and less heavy. But the SM’s responsibility is to ensure that they are aware of the sprint’s health all the time.

Estimating is not necessary for producing software. As it is with documentation, estimates by itself will not lead to working software. But they do serve a purpose in your organisation. Hence consider their purpose and then see if there are alternative creative ways of achieving the same.

Concluding Thoughts:

There are certain practices that are important for new teams to perform so they can mature to the point where those practices are no longer necessary. Skipping past some of those practices too early can result in increased failure and disillusionment.

One of the key philosophies of Agile software development is to have information radiators visible on the wall so that the progress of the team as well as what team currently is working on gets clearly visible to anybody who visits to the team area. That includes stakeholders, project managers, team or anybody from the organisation.

However, haven’t you observed that many times, as you look at the card-wall (Scrum Board), things are not very clear to you. Card wall may look like the mesh of user-stories with statuses in To Do, In Progress or Done. However some of the bigger questions are not clearly answered by just looking at user-stories.

For instance:

• What part of business process, team is working on in the current iteration? The whole business flow may contain multiple user-stories and epics. By just looking at the card-wall, business flow itself may not be clear.
• How much solutioning is done for a business flow and how much is remaining?

How about having a pictorial view of whole business flow as a process-map, identifying the user-stories (work to be done) in it? Take a look at a process flow below and you find some numbers mentioned on it. They are user-story ids.

If you take a closer look, you will find that some of the user-stories like story 2 are common to multiple business flows.

By looking at process map you find some immediate answers:

• What all user stories need to be implemented for a particular business flow.
• What all business flows are impacted by a user-story? For instance in above process map, user-story 2 impacts two different business flows.
• Where are we in the implementation of a particular business flow? In above process-map some user-stories are colored with Green which indicates they are DONE.
• Along with above mentioned benefits, process flows provide a shared and common place to have conversation on business flow within team and with Product Owner and stakeholders.

While looking at process maps, I realized that Story Mapping concept coined by Jeff Petton deals with similar issues.

Let me provide a brief overview of story-mapping.

The idea of story-mapping is to groom Product Backlog in such a way that you have “big stories” (termed as “user activities”, epics or features also) at the top of map. These big stories are divided further into user tasks (something that someone does to reach a goal).

For example for an email system I might have an activity such as “managing email” which then can further broken down in user-tasks or smaller user-stories like “send message,” “read message”, “delete message” etc.

Big stories are captured on the top in horizontal fashion and smaller stories are captured underneath of each big stories.

Story maps are great information radiators. However they may require big space to capture stories of entire release. Also story-mapping doesn’t necessarily provide information on the linkage between stories or how those epics/user-stories are orchestrated together to reach a business goal. For instance at what place of the process, a particular epic is applicable and why. It’s obvious from email example as everybody knows about it anyway. However it may be difficult to decipher for domain specific user-stories.

Process maps help in solving these issues. Instead of having all stories on board, you instead put a big poster of process map embedding the user-story identifiers in it. Process-map in itself is also a narrative and helps people to come on the same page.

Though based on above discussion, it may look like that process maps and story maps are completely different concepts to solve the same problem but they are not. They are tools to bring more clarity on the board. Depending on the context, they can be used to complement each other. I personally have used process maps to come up with story maps. Eventually the combination of both looks like following which is great as you have narrative of business process and at the same time you know the functional chunks/features/epics and user-stories of the solution with story maps.

Please note that above picture is just a representation of how process-map and story-map looks together. You don’t need to go to the details of which process-map step maps to which story as that’s not the intention of this image.

Demo is an integral and important part of Scrum ceremonies. Important because that’s the whole point of being Agile. You get early feedback from Product Owner and stakeholders and fine-tune the product if required. Also this is sometimes the only occasion for offshore team when sponsors and business actually get to see the real contribution of offshore team. There are valid reasons also when someone from onsite team gives the demo. They include:

• Language problem. I worked with a French team in which stakeholders and business were more at ease to talk in French.
• Completely opposite time-zones which may not allow a lot of collaboration.

The advantages of distributed demo far outweighs the ones of onsite demo.

Here are some of them:

• Offshore team interacts with Product Owner and stakeholders and present what they have developed in the sprint.
• Provides a sense of achievement to offshore team-members at the end of sprint.
• Team gets direct feedback from Product Owner and Stake Holders instead of getting through filtered channels.
• Offshore team-members get more visibility with customer which is important from trust-building and transparency point of view. Otherwise customer gets very hazy view on what offshore team does which in turn may lead to question their capability.
• Team-members who developed the functionality can provide better answers to the feedback questions.

Along with customer’s node and defining a convenient time which works for both teams, right tooling is essential. For screen-share and video conversation, in the past we have used Skype extensively which is free as well as efficient. Some people have been using Google hangout too. There are some screen-share only softwares also like yuuguu and mikogo.

Many enterprises are using Webex quite successfully. In order to make it work efficiently, along with good tools, good bandwidth, right webcam and mics are essential. It’s advisable to set and check infrastructure a little early before the demo time. It’s also good if the same people who developed or tested the functionality give the demo. Again that’s based on comfort of the team.

Waterfall made a clear demarcation between developers and testers. While moving from waterfall to Agile, both development and testing has to be grinded in a way that you can’t separate from testing activity from development.

People in Agile projects are moving away from “developers vs testers” (we vs they) culture and are collaborating in order to deliver the product at the end of sprint. Sprint success is major goal instead of developer or tester success.

That has been a great change in the recent years and which also means some more miles to go before reaching the state of true collaboration. Even today, quality is considered to be the major responsibility of testers which in reality shouldn’t be the case.

As developer is primarily involved in developing the functionality, (s)he needs to have tremendous commitment in building quality into source code and if bugs come, primary responsibility should be of developers. It doesn’t mean that testers don’t have any responsibility. They need to move away from their traditional role of just finding bugs and instead should be able to focus on creating infrastructure, frameworks for building quality within and also focus on exploratory testing, improving product etc.

In Automation testing, though automation test creation is the responsibility of the testers, developers lay the foundation of creating those test cases.

Sometimes this demarcation doesn’t work in a smooth way. While developing the automation tests, tester discovers many basic foundational pieces missing, which eventually hampers the tester in developing those tests.

In one of the teams I worked with, team came out with a norm which helped the testers a lot.

Developers suggested to write the first functional test of the user-story themselves, which laid the foundation and provided all required resources to build further tests. While developing those tests, developers identified many issues which otherwise would have blocked testers. As developers eventually fix these issues, it made much more sense that they themselves discover those issues.

Based on this basic foundation, testers further elaborate the test cases and create more automation tests. The norm worked pretty well for the team and also helped developers understanding the issues testers face on daily basis.

It’s step ahead towards ATDD. However this team was not using BDD or tools required for ATDD and was not planning to move towards them in near future. Developer-first norm worked quite well for them.

Genchi-Genbutsu is the Japanese expression for a practice of finding your answers right down at the source, rather than relying on second-hand reports or charts of data to achieve true understanding. This practice emphasizes going to a place(gemba) where you watch, observe and ask “WHY” five times. I shared few posts earlier on 5 Whys.

Most of the time we are hidden in our project plans and design documents to find root causes. Traditional methods assumed that having a great plan and good documentation is the secret to project success. They alienated themselves from implementation and real world.

Agile, on the other hand, believes in delivering some thing early on to confirm our understanding. It inherits the expression Genchi-Genbutsu.

For example:

• Working software is a way of confirming your product
• Sprint retrospective is a way of confirming your process.

Does it work? What is working? What we should do to make it work?

“Gemba attitude” reflects the idea that whatever reports and measures and ideas are transmitted to management, they are only an abstraction of what is actually going on in the gemba to create value.

Few anti-patterns that you see often:

• ScrumMaster sitting in a cabin rather than sitting with the team. Not having Gemba attitude
• Team and management working on a problem manifestation rather than finding root cause

You actually do a sprint, observe patterns and anti-patterns to find actual reasons. Curious folks will not spend time on creating a long plan or documents and sit on it for few months. They’d rather want to go and explore to find the truth by actually implementing it.

I believe we need Curious People on our Agile teams over Smart people. But, how many of us have the privilege of remaining curious after years of schooled conditioning? Take a look at the TED talk by Ken Robinson, in which he asserts that schools do not allow creativity to thrive.

I have come to understand this in my home-schooling  journey with our daugther – that Learning is NOT locked up in books (and, for that matter – in documents or in Project Plans). Why, then, do we see learning separate from living?

The idea of dev-box testing is simple but very effective. Let’s take an example of a development cycle:

1. Developer implements the functionality along with unit and integration tests and when she’s satisfied she commits the source code in the source code repository like svn or git.
2. Continuous Integration (CI) gets triggered by source code commit and CI tool like Jenkins performs the automated build which results in code compilation and execution of the test cases (unit, integration and automated functional tests).
3. After multiple builds when developer thinks that functionality is ready for functional testing, she asks the tester to take a specific build and test.
4. Tester starts testing. If tester finds bugs in the functionality, she informs the developer about the problem and developer again begins from step 1.
5. If everything is good, tester moves the user-story into DONE state.

Working through step 1-3 takes a lot of time and if testers has to move the story again in development, it results in a lot of time-waste and frustration.

How about this?

As developer sees everything working on his machine, he asks tester to test the functionality on his machine. While testing on dev-machine if everything works, only then developer commits the code which eventually triggers the build and auto-deployment. On the committed code available in testing environment tester performs further exploratory tests. Otherwise developer continue to fix the issues on his machine. This way, a lot of valuable time is saved.

Let’s take a scenario.

You have a product owner at distributed location but somehow he is not able to provide sufficient time to distributed team. Because of that team doesn’t get enough understanding of user-story.

Does it sound familiar?

Mostly it’s about PO getting involved in too many other things. That results in not having user-stories READY, analysed or communicated properly.

That brings another question related to suitability of people assigned for PO role. Not everybody is good in analysing and writing good user-stories.

For a combination of “not having enough time” and “not having right skills to write user-stories” issues, I observed it’s good to have an additional role which fill this gap. While working in recent projects, I realised that’s the role of Business Analyst.

Before jumping into solution mode let me clarify that the immediate and ideal solution is to balance actual product owner time. However in reality sometimes that’s just not possible because of many other constraints at customer side. Having a business analyst helping PO doesn’t mean that PO doesn’t interacts with the team. Business Analyst is still part of the team and PO still spends time with the team. However BA takes lead from team perspective in helping PO and shaping user stories.

In the past, we tried to implement the idea of establishing testers as pseudo Product Owners. But in reality, they have different focus areas and skills. It’s great to have additional business analyst skill along with a tester but not all testers have that kind of mindset and understanding of problem domain. Business Analyst need to have holistic picture in mind while thinking about business solutions. If tester’s mindset is just limited to the tests and finding bugs, it’s difficult to realise BA role with a tester.

Apart from right mind set, if you work on vendor side, as a tester you may not have sufficient domain skills as projects keep on changing. Community of experienced domain testers is in rarity.

In that context, I feel it’s important to have the concept of specialised Business Analyst role. Business Analyst continuously has a discussion with PO and team and come out with user-stories. PO provides participates in the discussions, provides all sufficient inputs and engage with related stakeholders. PO also takes the prioritisation decisions based on business priority and cost of the user-story.

BA becomes the point of contact for the team in case team has any questions related to user-stories.

I have seen this working well in many projects. However while solving one problem, you may get into yet another problem. The problem is – some times BAs are just focused in transporting information to the team and in process might be working as postmen, which is dangerous.

The idea of having BA onboard is not having a postman in the team but to provide a good amount of value add to the customer. For instance questioning if the user-story really provides any business value, questioning team if the proposed is the right solution or if there are simpler ways to do the same. Some times technical solution may not be the right solution for a given problem.

Conclusion

If Product owner is dedicated to the project and has good analytical skills from functional point of view, that’s ideal. However many companies work in constraints which doesn’t allow them to have a dedicated Product Owner. In that context, I find having a role called Business Analyst works very well for the team, especially for distributed teams where most of the issues are caused because of communication gap, insufficient information and unavailability of the product owner.

Off-shoring in current market is a global economic and strategic need. Building Agile Offshore teams across boundaries and time zones is a different ball game. It has its fair share of challenges to work with. I shared few of those challenges and a possible approach to take in my earlier articles.

1. How to Address People and Communication Challenges
2.Distributed Agile:10 Best Practices of Successful Teams
3. Distributed Scrum: A Day In The Life Of A Distributed Team

You need to make few changes along your way to your normal routine to make it work. One challenge I often see is integration of offshore team with onshore team and to project/business vision.

Lack of proximity to business is a big challenge. You could address this by making people travel, meet face to face, video conferencing etc. Your Product Owner may be very flexible, takes part in every daily stand-up, he is there during his core hours and ready to stretch some times. Let’s assume you have all of this, but still not having business representative at your disposal is an inhibitor to offshore team success.

How do we address this?

Creating a proxy business representative i.e Proxy Product Owner can be a secret sauce to address this gap.

• Assign an offshore team member preferably with business analysis skills as proxy product owner. This person is responsible for comprehending requirements and knows reasoning behind current prioritization of requirements.
• He works with offshore team to convey and clarify business requirements during offshore team core hours.
• He works very closely with product owner and meets face-to-face periodically(say once a quarter).
• If you have distributed team with less or no overlapping hours, PO proxy becomes very important. He will present stories to the team during sprint planning and for all practical reasons this person becomes product owner to local team.

This is also a big risk to the team as it may lead to some miscommunication. There could be instances where-in PO proxy may not be aware of big picture and hence unable to answer team questions with authority.

Backlog grooming or refinement session can address this. Scrum teams must have this meeting as part of their scrum ceremonies.  In this session, entire team, product owner and proxy product owner come together to discuss new and upcoming requirements of product backlog.  This gives offshore team to hear and connect with actual product owner directly.

Two anti-patterns to watch for…..

1. I see often, MAKING Under-powered,  Indecisive person as PO Proxy for offshore team. This will create more confusion, conflicts and miscommunication. This eventually leads to slowdown in decision making and a decrease in productivity and morale. Watch-out for this pattern. 

   Just calling business analyst as Proxy product owner is not a solution. Proxy PO is given free hands to make decisions.

2. Second anti-pattern which is observed is supplementing low bandwidth busy Product Owner with a so called Proxy PO to help him. This is solving a wrong problem. You need to balance actual product owner time at the first place.

Concluding thoughts…

Going for Proxy PO has some risks.  It adds up another extra layer in decision making which is not ideal.

I favor going for proxy PO for addressing vast time zone differences. Additionally,  having business person on offshore side, helps in building big picture, domain expertise, alignment towards business vision and also makes wonders to offshore team confidence and morale. Offshore teams work as business partner rather than implementation partner.

Please share your story of how are you managing lack of business proximity issue with offshore teams?

Simplicity at work – I h’ve always wondered what does this mean to me, to my team and to my organization. In my quest to know more, I asked this to many Agile Coaches and enthusiasts on various groups.

In this post, I like to share what I understood and gathered from my interaction with these people: Steve Ash, Charles Bradley, Lynn Shrewsbury, Ruud Rietveld, Philip Ledgerwood, John Hebley, Jeff McKenna, George Dinwiddie, Adam Sroka, Michael James, Matt Anderson and Cass Dalton.

Decluttering is a consequence of Simplicity. Simplicity leads to:

• Decluttering of products.
• Decluttering of your mind. Not being manipulative – being honest, open and trustworthy.
• Decluttering your workspace, working in open spaces.

The desirability of simplicity is sometimes expressed as the KISS Principle.

• Do today only what you absolutely need to do today. No ‘future-proofing’.  No  ‘gold-plating’.
• Achieve Just Barely Good Enough (JBGE). JBGE is actually the most effective possible.

Thanks to Scott Ambler for sharing this term JBGE. You could read more about this in my earlier post Agility is About Identifying and Achieving “Good Enough”

There is a point in time when any additional effort put into work product will increase its cost without increasing its value. If not zero, the increase in value may be insignificant compared with the increase in cost. This is the point to stop! (Achieving JBGE).

It’s easy to continue developing a product beyond some point. A Standish Group survey in 2009 stated that over 70% of functionality is never or rarely used. Not doing that work is a great opportunity to do more valuable work.

Few Agile thinking and practices that come to my mind are:

• Test Driven Development follows simplicity. You right just enough code to pass your tests. By defining the measure of success first and then coding to that (and only to that), you eliminate a lot of unnecessary work.
• Building working software just enough to get feedback.
• Writing just enough documentation to serve a need.
• Use of story cards (As a customer, I want to do something, so that I can get some value). You don’t do anything unless the value can be clearly stated.
• Using simple task boards to measure progress.
• Backlog refinement: Product Owner decluttering backlog to identify features that will make his product successful. Check my earlier post Scrum Product Owner Has to Kiss Lot of Frogs to Find a Prince
• Having only 3 roles in Scrum (Team, ScrumMaster and Product Owner) on a team is simplicity.
• Thoughtful reduction of hierarchy within the organization is a step towards simplicity.

XP-term ‘YAGNI’ (‘You Aren’t Gonna Need It’) defines simplicity. Teams want to create more than what is asked for, because, we are going to need it further down the road. But the road can go in a different direction soon, and then all the work is wasted. Hence better do it simple now and only embellish when it is actually needed.

• Keeping design simple eliminates the need for supporting documentation.
• Simple design approach reduces unnecessary work done upfront.
• Doing refactoring now keeps code and design simple and easy to change with less effort.

In software development, teams often add work that can be easily avoided as they are not adding any value. Work such as:

• Delivering features that nobody asked for.
• Gold plating things that are already shippable.

When organizations are building software, they do certain things that are necessary in the scheme of things. But, these tasks demand time and effort that could be put to better use.  Not to say that these should be skipped altogether. But, there’s definitely a way to achieve the same purpose in an easier way. What are those tasks? Let’s list them below:

• Requirement documents are not necessary to understand the requirements.
• Design documents are not necessary to design software.
• Estimating is not necessary for producing software.
• Documenting test cases are not necessary for testing.

None of the above themselves contribute to the final product. Like I said, they serve a purpose in your organization even though they do not directly lead to working software. Consider their purpose, and consider other ways to achieve the same purpose with less time and effort. Else, you’ll end up with a pile of ‘actual work’ not done.

There is a tendency within developers to design the generic, scalable framework first, before having more than one real example to implement that uses the framework.  You never really know what generality you really need until you have several data points.  The leaner/agile solution would be to write the first implementation in the simple way just to get the product in front of people.  Once you have a need for a second or third case, then this will have a much better idea of how much of your generic framework is really generic and how much of what you would have written into the framework was either unneeded fluff or actually specific to the first implementation.  In this case, the simplicity allows you to not to over-engineer the software.

In one of the group conversation, Charles Bradley shared a link from his blog. Check this to find what Ron Jeffries and Chet Hendrickson have to say about Simplicity.

Please share your story of how did you and your organization applied simplicity principle.