Tuesday, September 20, 2011

Developing Organizational Standards to Support Agile Teams

Abstract
At the department level, Agile processes are less descriptive on how to increase delivery excellence across all their teams.  One approach is to provide implementation-free constraints/goals that drive teams to better delivery and then encourage a culture of cross team information exchange.  The constraints/goals will create direction and incentive for teams throughout the organization, while information exchange at the team level allows new 'best of class' solutions to these constraints/goals to propagate across the organization.  By inserting a few organizational standard items into  team Working Agreements, using Build Monitors to make quality visible, and learning events such as Book Groups, the organization can create a minimum "bar" across teams that will force some teams to improve their delivery excellence, yet won't get in the way of teams who already have good delivery excellence (yet potentially non-standard though innovative development methods).

Introduction
Most agile methodologies come with a built-in form of information exchange at the team level:
daily standup meeting, retrospectives, sprint demos, pair programing, planning meetings that include the entire team, retrospectives, and code reviews.  eXtreme Programming, for example, contains the most extreme form of team viral information sharing--pair programming, which has developers working with each other and improving all their development craftsmanship on a daily basis (including soft skills), but sometimes people can't get along with each other.  Other forms are lightweight and helpful, but reduced efficiency--code reviews, for example, help people become better OO programmers (a part of craftsmanship), but the practice increases work-in-progress, creates an additional future integration point (integration of design ideas), discourages code experimentation (might not make it past the code review), and doesn't help people learn how to use their software tools such as the IDE more efficiently.

Although most Agile methodologies come with good information exchange at the team level, finding how to direct efforts across the organizational is rarely discussed.  (Scrum has Scrum of Scrum and Meta Scrum.  Others practices?  Please use the blog comments to add more knowledge if you see something missing.)  Here are strategies that I've seen implemented to a good effect across an organization and creates a minimum bar of delivery excellence across all the teams, forcing some teams to discover better ways to deliver code, yet doesn't disrupt teams that already are excellent at delivering code.

Working Agreements
The best working agreements have fewer than eight items and are visible in the team's working area.  Here is Fred.  Off camera is the rest of his team.  Although this working agreement was developed by the team, organizational standards were incorporated without being "too" proscriptive.  This way, the team takes ownership of their "implementation" and use their own tools/processes to accomplish the working agreement.

Team Working Agreement
Teams get a lot of value by having a written agreement on how we work together and handle day to day issues.  This agreement often puts into writing the answers to the "typical" questions that non-self directed teams recieved by asking their project manager, "hey, this happened, what should I do?"  This working agreement is often referred to by the following names: Team Working Agreement, General Working Agreement, or Daily Working Agreement.  The editorial comments in parenthesis aren't explicitly written down on the working agreement, but are understood by the team.

Example:

Team Working Agreement
- Automated tests are added for all discovered production issues before the code is written
- Standups always include a dial-in (for teams that have remote team members/PO)
- solving production fires is top priority
- stop what your doing to address failing automated unit tests
- the state of all automated tests is visible in the team area
- all system tests, unit tests, UI tests are executed by CI
- all unit tests are executed at least daily
- comprehensive test passes are executed before release to live (all automated + manual)
- all code changes are developed using TDD (legacy code and new code)
- QA starts writing system tests on day one of sprint
- everyone is a tester

Organizational Standard
Setting some core standards across all teams about what few items must be in Team Working Agreement works well.  Common subset of the above that I've seen in practice are:
  • all system tests, unit tests, UI tests are executed by CI
  • all unit tests are executed at least daily
  • visible burndown chart
  • Scrum is practiced (this is usually implied)

Story Definition of Done       
This is the team's agreement on what "done" means when they say, "this story is done."  All the steps to the story being done must be met to get "credited" with the story being finished so the team can accumulate the story's estimate in Story Points/Units into the team's Velocity.  When the team starts a new Definition of Done, the SM needs to be vigilant until the team has got it.  If the team can't follow it, then we look for "why not" in the Retrospective and find some way to handle the impediment (fix some problems, adjust definition of done)  This definition of done is important for maintaining the team's standard of potentially shippable at the end of each sprint.  The editorial in the parenthesis isn't typically added to definitions of done but understood by the team.

Example:
Story Definition of Done
- All public methods are unit tested  (except for machine generated code that isn't changed by human hands, or DataValue objects that are "identity--I=I" getter/setters)
- Story functionality is tested with an automated system/UI test (also called acceptance tests, functional tests, ...)
- Manual tests are executed
- Rally is updated (Rally is an electronic story tracking tool)

Organizational Standard
  • all public methods are unit tested
  • stories have automated system tests (also called acceptance tests, ...)
Sprint Definition of Done  
Because a sprint is time boxed, the sprint is finished regardless of the "pass/fail" of the items in the Sprint Definition of Done, but the retrospective should be used to identify the root causes and create actions to solve problems.

Example:

Sprint Definition of Done
- Each sprint, the code coverage increases
- All automated tests are green at the end of the sprint
- All manual tests for the stories are executed

Organizational Core Standard
  • code coverage increases each sprint
  • design issues go down each sprint
  • automated test count (system and unit) goes up each sprint

Other Working Agreements
The following working agreements may also be useful to teams.  The art is to find the fewest agreements so we aren't buried by paperwork and yet have the ones that are necessary because problems happen when we don't have them: Task Definition of Done, Release Definition of Done (contains activities to be done before the software goes live, such as performance testing, security testing, or other things that for some reason, there are impediments to getting them done during typical sprints.)

Build Monitors
These devices show the "headlines" of the projects quality status.  Anyone can "click" for details.  This team modified the continues integration system's CSS to get the clear and simple style they wanted.  (Unfortunately, most CI environments have overly complicated dashboards.)  The monitor the left has the biz tier (unit tests) and web services tier (system tests) for the SAME app.  The build was split into logical levels.  The first level compiles, then runs unit tests for the biz tier, and then runs system tests for the web services tier.  The monitor on the right is the system tests that test the UI.  These three levels are common.  It's not hard to imagine adding a SQL level would be useful for a team doing work with stored procedures.  The success of one level cascades to the next level.  A failure at level one (can't compile) stops it all.

Book Groups
Books a great way to get information across many people in an organization.  Just buying everyone in your department a book is a weak play (I still haven't read "The HP Way" which was given to me by my manager when I started work at HP).  Books are great learning tools if they are actually used.  I don't recommend buying people books unless they ask for them or it comes with a plan reading and using the knowledge.  Book groups are groups that get together and discuss reading and using the knowledge (or actually demonstrating the knowledge).  To encourage the Cross Pollination of Information, find someone to start a cross organizational book group that meets each week over lunch (companies often buy lunch and the books, and if people are meeting about the books).  Encourage the group to develop activities to put the knowledge to work: get members to sign up to teach or demonstrate or lead discussion for each chapter of the book.  DO-CODE-ON-PROJECTOR with a mob watching is my personal favorite tactic.  Books I recommend are: Martin Fowler's Refactoring, Diana Larson's Agile Retrospectives.  Teams I've been a part of have done this with books on Refactoring, GOF Design Patterns, eXreme Programing Explained, and Java Concurrency.

Conclusion
Delivering to all your teams core standards for their working agreements creates quality bars that teams aim for and hurdle over.  If the organization focuses on the desired outcome and allows the teams to develop how to reach those outcomes, the teams will find solutions that work best for their personal and project makeup, and they'll become vested in the implementation.  Adding in collaborative cross-organizational sharing and learning events such as book groups that are driven by employees, will give the employees a process for driving their own development and collaborating/learning with other team members.  

Troubleshooting
Here is a troubleshooting guide that covers some common problems that may occur implementing the above activities.
  • Team finished sprint with zero velocity.
    • Maybe their working agreements were too hard.  Inspect and adapt for next sprint.  Maybe they need to embed a coach for a sprint.
  • Team releases with bugs.  
    • Not enough testing.  Zero bug releases are expected.
  • A team's CI environment isn't visible
    • Are their tests failing?  What are they hiding?
  • Team refuses to try new practices/process for even a sprint.
    • Too much release pressure?  Team embedded in their old ways?  Is the company culture so risk adverse that any failure has political implications?

References:
XP practices http://en.wikipedia.org/wiki/Extreme_programming_practices

Thursday, September 8, 2011

What do studies say about Agile?

Agile Studies
This is going to be a different posting.  This one will be organic and added to as I find other good bits of information.  I need something like this to make it easier to go over an inventory of studies.  I need this to solve my "searching for studies" impediment which comes up periodically.

Help me keep this up to date.  If you have an Agile paper you want cited, comment about it. 
Refactoring:
 Understanding the Economics of Refactoring
Abstract: A novel method for estimating the expected maintenance savings given a refactoring plan. This work is motivated by the increased adoption of refactoring practices as part of new agile methodologies and the lack of any prescriptive theory on when to refactor.
Lance's Summary:
  • best to refactor code that is going to be changed a lot in the future, so pay attention to where your rate of change is and keep that code clean
  • a guideline is that your refactoring pays for itself after six times you needed to revisit the code and change it
Abstract: Code quality remains an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for time-to-market and new features. The resulting technical debt is estimated to waste up to 42% of developers’ time. At the same time, there is a global shortage of software developers, meaning that developer productivity is key to software businesses. Our overall mission is to make code quality a business concern, not just a technical aspect. Our first goal is to understand how code quality impacts 1) the number of reported defects, 2) the time to resolve issues, and 3) the predictability of resolving issues on time. We analyze 39 proprietary production codebases from a variety of domains using the CodeScene tool based on a combination of source code analysis, version-control mining, and issue informa- tion from Jira. By analyzing activity in 30,737 files, we find that low quality code contains 15 times more defects than high quality code. Furthermore, resolving issues in low quality code takes on average 124% more time in development. Finally, we report that issue reso- lutions in low quality code involve higher uncertainty manifested as 9 times longer maximum cycle times. This study provides evi- dence that code quality cannot be dismissed as a technical concern. With 15 times fewer defects, twice the development speed, and substantially more predictable issue resolution times, the business advantage of high quality code should be unmistakably clear.
Lance’s summary: I like where this paper is going but I’m not sure how to measure the ROI of coaching teams without:
-  measuring the code base in pre-sales
- creating a model that expresses likelihood that the code that’s being refactored is “the right code to refactor.”

STATIC CODE ANALYSIS, Alexandru G. Bardas, 2010

Abstract: This 9 page paper published in Romanian Economics Business Review mentions economic reasons for software development teams to use static code analyses as giving a 17%-27% reduction in ownership cost due to problems being discovered during the code creation rather than escaping into production. 

Test Driven Development:

TDD Improves Quality
Abstract: A paper first published in the Empirical Software Engineering journal reports: "TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team." The study compared 4 projects, at Microsoft and IBM that used TDD with similar projects that did not use TDD.

Does Test-Driven Development Really Improve Software Design Quality?
David S. Janzen, California Polytechnic State University, San Luis Obispo Hossein Saiedian, University of Kansas
Lance's summary: TDD allows simpler design == less lines of code to do the same thing
Summary: Software developers are known for adopting new technologies and practices Software developers are known for adopting new technologies and practices

Test-Driven Development and Software Quality
Lance's summary: a blog that comments on the IEEE paper "Does Test-Driven Development Really Improve Software Design Quality."

Lance's summary: Yes, unit testing alone has measurable economic benefits, but the benefits are less than TDD.

Pair Programing:
A good summary about the practice along with a little satire at wikipedia.

The Costs and Benefits of Pair Programming
Alistair Cockburn & Laurie Williams

Lance's summary: Pair programing creates a lot of value over the total product lifecycle (higher code quality, lower defects, reduces team bottlenecks, and increases work satisfaction) at the cost of 15% more development time.

ABSTRACT
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.


Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise
Erik Arisholm, Member, IEEE, Hans Gallis, Tore Dyba ̊, Member, IEEE Computer Society, and Dag I.K. Sjøberg, Member, IEEE

Abstract—A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time.

All I Really Need to Know I Learned in Kindergarten
By Robert Fulghum (Fulghum 1988)
Lance's Comment: Not really a study, but important information for people interested in pairing studies.  This paper contains a lot of the behaviors needed for successful pair programming.

Abstract:
Share everything.
Play fair.
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt somebody.
Wash your hands before you eat.
Flush.
Warm cookies and cold milk are good for you.
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Take a nap every afternoon.
When you go out into the world, watch out for traffic, hold hands and stick together.
Be aware of wonder.

Pair Programming Testimonials
Abstract:
If you would like to share your pairing experiences or read about other people's, this is the place. Describe the good and bad of your experiences pairing to help others in a similar situation - just a paragraph or two would be great . . . what worked well, what didn't work so well, what kinds of things did you 'attack' together, tips and tricks, etc. A great example of a testimonial is by Ron Jeffries in the July/August 2000 IEEE Software page 25.

Economic Cases for using Agile software development techniques: 
Abstract:
This study takes a look at several business in several industries (auto manufacturing, financial services, ...). One of the conclusions is about the cost of rework (cost of change curve) is exponential. (See Table 1-5)




Friday, September 2, 2011

The ONE right way to Scrum

What is the right way to Scrum?
This question is brought up a lot in organizations that are transforming to Scrum to improve their ability to deliver products. It's a natural question for smart people to ask when they are receiving Scrum training and then discover other teams adjusting from the "default" or "standard" implementation of their company's Scrum process.

Is there one way to do Scrum?

It's better to ask yourself, "should there be one way?"

When anthropologists talk of societies and biologists talk of evolution and virus colonies, history has shown that the results of monocultures are dangerous. The societies, governments, organisms, or colonies that survive are those that could respond to a change that wiped the others out. Having everyone thinking and agreeing all the time means new ideas aren't getting tried out. On the other hand, having only conflict/chaos means poor productivity/survival.
Computing monoculture
agricultural monocultures

What is Scrum?

Scrum has been around for over 10 years.  (You can read Martin Fowler's 2005 overview of Scrum in
The new methodology called Scrum)

Scrum says once the planning meeting has finished and the sprint starts, the planning conflict (conflict over resources) is over (or at least is moved outside the team) and the execution of the plan begins. For the team, conflict moves to technical implementation as they discover the best designs (test plans, class designs, craftsmanship) to meet the plan's goals. At the end, the team, ScrumMaster, and ProductOwner inspect the results and proposes a "new experiment" to improve software delivery.

What is Scrum (or basic scrum)

Three roles: team that does the project work, a ScrumMaster, and a single person to be ProductOwner.
A fixed backlog of work for a sprint.  A sprint is a fixed length of time.
A quick planning meeting.
Retrospective and sprint demo.
Daily standup meetings that are no longer than 15 minutes.

*Velocity, burndown charts, and task boards are also expected but aren't necessary for the empirical process other than adding more visibility. But since visibility is necessary, like a microscope is necessary to a biologist, I'm including them too.

You may ask six Agile Consultants "What is Scrum" and get six answers but I expect all six will have at least all the above.

Why six different answers?
How I Scrum today is different than how I Scrummed in 2006. How I Scrummed in 2006 is different than 2004 (my first Scrum project). But in all cases, I did Scrum. Before 2004, I did eXtreme Programming, and did not do all the above that is Scrum and instead did other things, XP practices (pairing, TDD, system test) and how my team executed those practices changed every month/year.

Why did my practices change? Because my teams inspected the WAY we did things and ADAPTED. We talked to and learned from others doing agile and tried out ideas for a sprint. Using the rigors of the experimental process (control/fix everything else but what you want to change, and then measure the results at the end) we decided what new adjustment to keep and what not to keep.

Standards

Should there be a standard way across an organization?
Are you saying that you want a monoculture? Is Scrum itself a monoculture? Maybe, but if each Scrum team is a little or a lot different so I think it's not a monoculture. I think that doing "basic" Scrum (just Scrum) as a standard is a good idea because then everyone from development to the CEO understands the culture enough not to:
Ask team members multitask across different projects
Ask POs to change the team's sprint backlog while they are in mid sprint
Discourage highly collaborative practices like Pair Programming
Discourage differences between Scrum teams
Ignore impediments discovered by teams

We want how we work together standard enough to not break each others' Scrum processes and to support teams' inspection and adaption of their own processes.

Directing an organization without standardizing a monoculture


Standardizing on organizational goals that allow teams to self organize is a good idea. Here are some I've seen in the industry:
burndown chart of some kind, definitions of done,
Automated system tests, automated unit tests, a system to show how many tests are passing/failing in the last hour, collocated teams, a highly visible team task board the team can use throughout the day, current code coverage and sprint by sprint history so we can see the trend.

The one TRUE way to Scrum

When an organization leaves Waterfall for Scrum, people need to be well trained on what is Scrum and asked to do things they are uncomfortable with, maybe even things they can't imagine could work. They need this pressure to get started doing Scrum otherwise, before even their first sprint, they decide to inspect and adapt to something they are comfortable with, Waterfall, out of a sense of comfort rather than out of quantifiable measurements that come out of the Scrum process (Velocity is a big one). So to get a team started, they will need to take a starting Scrum model on faith until they get the idea and see results good or bad. After a few Sprints, I expect to see that the cumulative affects of inspect and adapt to show some changes from their starting Scrum model but to still see the basic Scrum model intact.

If someone says that they have one true way to do Scrum, I'd start walking the other way because that person doesn't understand that Scrum requires teams to inspect and adapt their process to become efficient for their specific situation. If a team isn't inspecting AND adapting, then their Scrum process is broke.