Scrum Development Blog

Team Swarm

The 3Back Team — Thu, 11 Mar 2010 19:16:32 +0000

Team swarm is an observable pattern of cohesive team work. The word swarm is the right word because to an outside (outside: someone not directly on the team doing the work) observer the pattern almost looks random. However, to those on the team they are moving with intent and purpose even though the observer cannot easily discern why they are focused the way they are.

Well formed teams will exhibit a team swarm pattern after they mature. A good sign of your team maturing is that they tend to swarm and jump on work together and often one story at a time. This is an observable point of view that the Scrum Master can use to detect when his/her team is starting to work well together. To an untrained observer this will be a sign of chaos and the tendency is for them to step in and clean up mess “who’s in charge here anyway” or “this needs to be tidy’ed up”. These types of management practices are anathema to a good agile scrum team and interfere with it’s ability to self organize.

The pattern of team swarm is generally observed for teams when strong task orientation is present. Scrum teams are often working on software development problems that require a team head to work through. The Product Owner, in scrum, provides the direction or line of purpose for the team.

Great project management recognizes team swarm and is good at stimulating the environment to encourage small team tactical behaviors. A competent agile project manager will not usurp the teams work pattern to fulfill a desire to know what is happening. This means that reporting of work done on the agile team is incumbent on the team members to make it visible. Therefore a great leader charges the team with the constraint to both make it visible internally so that common task orientation and make it visible externally so that reporting/decision making can be supported.

The team swarm pattern is critical to decision making. Tactical agility (team level agility) can result when the work is visible and an emergent adaption can occur. Externally there is a need to supply concrete realities the team encounters to inform and enable strategic agility. Again this informs decision making both internal and external to the team. A trained agile project manager will know how to stimulate team behaviors without compromising the team’s need to self organize and simultaneously feed that information up the decision making apparatus of the organization so that strategic agility can happen. The result is a bidirectional flow of information. Team swarm is one way to know you are on the road to making that happen as smart as possible.

Code Viscosity

The 3Back Team — Wed, 10 Mar 2010 23:19:03 +0000

Code Viscosity is generally referred to as Technical Debt in software. The word viscous is a good metaphor because it describes something that would be hard to move through. We can describe the difficulty to move through code as viscous. Imagine swimming in syrup vs. water.

Deficiencies that show in code, development environments, and development practices. Technical debt generally makes the code hard to change. Typically, this includes bad design, poorly written code, poorly documented code, lack of a good unit testing framework and/or set of practices, bad configuration management, and so on. (see Quality Code)

Technical Debt Deficiencies in the code, development environments, and development practices, which makes the code hard to change. Typically, this includes bad design, poorly written code, poorly documented code, lack of a good unit testing framework and/or set of practices, bad configuration management, and so on. (see Quality Code)

Scrum Air Force

The 3Back Team — Sat, 06 Mar 2010 05:27:13 +0000

The scrum development air force is coming to Orlando for the March 2010 Scrum Gathering.

Effective Agile Dev LLC and 3Back LLC are excited to be at this years Scrum Alliance Scrum Gathering in Orlando.

Are you going? Then sign below in the comment section.

Agile Earned Value Metrics

The 3Back Team — Thu, 04 Mar 2010 15:31:54 +0000

For agile teams, earned value metrics is simple a way to measure and monitor an agile team. As long as the metrics are not used to drive performance but, instead used to understand throughput they can be a powerful aid. We will call this Agile Earned Value Metrics (AgileEVM).

In scrum or agile, we typically have a story as the fundamental unit of work being asked for. A team will then work on this request to complete the story. Stories are used to drive team work. With stories (chunks of work) we typically see a notion of story points for each story (story points is a relative sizing mechanism used to compare one story to another and gain an understanding of size over many small bites of work). Each story has a sharp definition of done or exit criteria that can be assessed for completion. Stories are shaped and written by analysis and through practice will tend to become roughly the same size chunk of work overtime. With story points we can form a stable baseline for understanding earned value metrics.

Our approach will be to understand our effort by using AgileEVM implementation according to the product backlog at hand and the demonstrable skill of the team. It is the demonstrable part that hinges EVM to an agile effort. Demo or demonstrably done in Scrum is formally called called Sprint Review in modern scrum. With a focus on stories we have AgileEVM. Note Value: is now anchored as a foundational concept by focusing on satisfying the request from an outside the team source (requests in agile projects are stories). By being fairly small or bitable chunks of work we have something that is granular enough to measure and allow us to pursue answers to the questions the business cares about.

Am I getting what I paid for?
Am I getting it as fast as I expected?
How much value am I getting?

With the patterns of stories and story points we can setup and make use of the concepts of Earned Business Value. In Scrum, the Scrum Master or Agile Project Manager would be key to getting this setup and monitored so that we can inform decision making.

Team Fragmentation

The 3Back Team — Sat, 27 Feb 2010 19:20:12 +0000

Team fragmentation occurs when there is a lack of unifying purpose in product development work. For simple groups this is often referred to as task orientation. Since the word task is so heavily loaded in agile project management or an any agile / scrum team our industry commonly uses team fragmentation.

In agile distributed teams can easily become fragmented from lack of task orientation. For a distributed scrum agile team this can be very challenging. Most organizations are faced with the reality of distributed team work in the form of offshore or nearshore typically done as outsourcing.

How do you manage these teams?
How do you bring new team up to speed?
What tools do we use?
How do you juggle time zones?
Language barriers?
Cultural barriers?
How do you form effective team habits and without getting blinded by process fog?

Successfully developing a product with a distributed agile team is a modern day challenge most companies. For the 3back team this topic is one of our favorite.

Process Fog

The 3Back Team — Sat, 27 Feb 2010 18:11:08 +0000

Too much structure, even well intended can obscure what is happening. Process fog can be thought of as a reduction invisibility brought about by creating too much process such that we can no longer detect how to tune team communication protocols. For this purpose there are 3 layers of fog that we can consider.

Quick Summary of Scrum

The 3Back Team — Fri, 26 Feb 2010 20:37:41 +0000

Quick Scrum Summary

What follows is a bulleted list for a rapid intro / reminder of Scrum. For Scrum a good metaphor to think of is Race Car, Driver and Mechanic. Can you guess which role in Scrum is Race Car, Drive and Mechanic?

3 Roles ScrumMaster (SM), Product Owner (PO) and Team

Team 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily standup detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Distributed Agile Teams

The 3Back Team — Thu, 25 Feb 2010 21:36:29 +0000

Distributed agile teams can work, but it is risky. Even more than traditional agile implementations, distributed teams tend to fall into two failure modes: “command as control” or team fragmentation.

Why?

Agile methodologies warn how critical it is to co-locate teams in the same room, but this is not always practical. Distributed or “virtual” teams are a reality of business today. Offshoring, flex-work schedules, multiple corporate offices, and other forces create pressures to achieve results even when team members are scattered across the globe.

But most of these distributed teams seem to prove the Agile warnings right by demonstrating old habits of waterfall behavior. Long cycle times and endless requirements revision are the norm, status reporting takes up far too much time, and individual leaders dominate the team. Management direction gets lost in a sea of process and tools instead of manifesting as tangible, quality product.

How can we realize the benefits of Agile product development – hyperproductivity, high-quality products, self-organization, elimination of waste, and rapid releases – when team members are not sitting next to each other? How do we make scrum distributed teams work?

This is the challenge of business in the 21^st century: how to work effectively at a distance.

Agile Model

The 3Back Team — Wed, 24 Feb 2010 17:44:56 +0000

6 Characteristics of a useful Agile Models.

To understand an agile model, we need to understand or define agile. Agile is adapting, adjusting, reacting, responding to change. In scrum it would be a team pattern. The notion of agility only shows up through time. When I talk about agile it is about balancing.

1. An agile model’s pupose is to enable balance.

An agile model be sufficient when it enables us to adapt / adjust. The Scrum Framework is an example of one such model. However,there are many agile models that are so abstract that they are essentially useless because they account for everything which means they handle nothing. So a good agile model will be barely sufficient or just enough of an abstraction that it helps guide my actions without consumming my mind with it’s complexity.

2. Agile models must be understanable to be useful.

When we abstract concepts we risk making abstractions that can cover anything. This is sorta like sand as a building material. I can make bricks with it, windowns, Honeycomb light weidght nano structures and tubes. Etc. While sand is a ubiqutious easily available building material the amount of time I spend getting into shape can be exhaustive and easily exceed the practical time available to do a job. Likewise and agile model must allow for an easy application to a job or it risks requiring to much work to be useful. In software development we have a history of creating one over the world frameworks that require enourmous effort to understand and use.

3. An agile model must be within the realm of expected purpose.

No model is ever 100% accurate. We use models to drive certain ideas into a software architecture but, the model itself is not the same thing as what we deploy or drive in. The model can be used to understand a system’s design and consider new ways to alter that design. But a model is exactly that a model. The thing is the only true representation of the thing. When we work with computers, I sometime call them boolean approximation devices. The software on my machine will always behave slightly diffently than the software that you install. We just might not be observiing those differences and not care because the behavior is within the realm of expectation for that purpose.

4. Agile models help us manage shifting levels of precision.

When is enough detail enough? Too much detail in anything can overwhelm our capactiy to understand. Sometimes we fall prey to the belief that if we have more information about x we must know more and therefore make better decisions. An agile model is a tool and a way to help us screen out noise and not pollute us with too much information. The goal of an agile model is to help us figure out how to effectively focus our intellect on our very real and challenging problems.

5. Agile models must somehow help us.

If the model is not helpful then through it away and get another one or extend the one you have to be useful. In either case we need to adapt our work to the reality of the problem space we are tyring to understand. An agile model should enable that adaptaion and not causes us to fight it.

6. Agile models are barely sufficient.

The provide focus on the right questions and help us have the right dialog to build understanding. Agile models by themselves are not the answer but, simply a tool to help us explore what an answer might be. Agile models enable us to work quickly through conversations by providing just enough.

So, an agile model helps detect the right conversations to have so that we can balance as we explore a problem space. An agile model is useful when it helps us detect solutions to a problem in a timely manner. We still need to build the solution.

Good agile models help guide the right actions.

Scrum Tools

brian.glatzel — Wed, 24 Feb 2010 17:23:05 +0000

There are many tools in the market that offer a way to stream line you work processes. From a white board and post-it notes to sophisticated software. How do know which scrum tool to use? Here is a list a few tools that may be helpful.

Select Scope Manager
A commercial web-based package that provides planning capabilties to all aspects of Scrum and XP projects. Evaluation version available to download from site. I’ve worked with some Select products in the past and they’re not bad, but not very customizable.

Scarab
Java server based artifact tracking system, highly customizable. Distributed under a BSD/Apache style license.

Scrum for Team System
This is an add-in guidance package for Microsoft Team System, it fully covers Scrum and lets you get work done fast. No customizable available but it works without it. This was co-developed with Ken Schwaber so it reflects how Scrum needs to be done. Let’s users create their own views but comes with a dozen or so that are quite sufficient. Supports single team or multiple team projects and is currently being updated to version 2.0 where it’ll have more flexibility. If you have Team System in place and are struggling with the MSF for Agile package then take a look at this, you won’t be disappointed.

Although there are dozens of software solutions tools for managing agile workflow, it is best to finds the tools that are naturally adaptable in your work environment.

Just about any tool can help you and any of these tools or others can become a barrier to your success. Make the tool serve your purpose. You should not feel like you are bending to the tool’s purpose. The tool must serve product development otherwise get rid of it.

Two common reasons you cannot get rid of a tool that is hurting you….

You cannot get rid of it is because someone else is mandating the tools use. Just because you paid a ton of money for a tool doesn’t mean it was a good decision and mandating a tool will not make the decision better but, it might save your career from political egg on the face. The team would dump it if they were allowed.
You must use a tool like the one you have to meet audit requirements. This shows up in regulated environments.

When you have the freedom to let the people who must use the tool on a regular basis make the call, don’t be surprised if this year they want tool “X”, and next year it is tool “Y”. What is more important is the ability to adapt!