Tuesday, September 2, 2014

Frameworks considered helpful

Jurgen Appelo recently wrote:

I know of no industry in the world that is as infested with methods and frameworks as the software business. Whether it’s RUP, XP, Scrum, AUP, DAD, or SAFe, it seems IT businesses are always looking for yet another method or framework that they can “implement” next month.

As a retailer, how often do you come into contact with filmmaking? Not very often. How often do you come into contact with road building? Except when you are stuck in traffic due to a construction site, not very often.

How often do you come into contact with IT? Every business comes in contact with IT. Whether to sell on online, automate processes, manage work, or whatever, every IT and software are everywhere. And IT projects can be extremely complex and failure is quite common.

And IT is so widespread, there aren't enough experts to go around -- or why does Jurgen tour the world to promote his book and his framework, instead of working with individual companies to help them improve?

Most people have no idea where to begin. Our instincts from our hunter-gatherer phases evolution are often counter-productive. So frameworks are essential. They are reasonably well understood place to start. Some of them even work pretty well, like Scrum (or even Kanban ;-) if you apply them reasonable well. And this is hard part.

For some more research-driven explanations as to why frameworks are helpful, see Chip and Dan Heath's book: Switch, or How to Change when Change is Hard. Their example on Minimally Invasive Cardiac Surgery is particularly illuminating. Taking on a new complex activity requires a good place to start, a lot of practice, and a willingness to learn.


Monday, September 1, 2014

Scrumbut, or What could you omit from Scrum?

Jelle van Wieringen recently wrote on LinkedIn:
Next Monday in Mannheim, Germany we will discuss Scrumbut in our open monthly "Scrum Stammtisch". This months topic is the consequences of leaving out elementary elements of Scrum. I'd like to know what [people] think...
As perhaps the first person to ask people to take the Nokia test in public, I feel a little bit responsible for the creation of the term "ScrumBut." Is it OK to change Scrum? Certainly there are situations where necessary, and others where it's not OK (and probably some overlap between the two!), so here is my take on changing Scrum:

The core of Scrum is really very small. Inspect and Adapt. At regular intervals. Everything thing Scrum is designed to enable effective inspection and adaptation at regular intervals.

To me, Scrum represents a solution to the challenge of solving complex problems based on those simple principles. It's a reference implementation. You'll never do it exactly like it is in the book, but especially at the beginning, you should try to get as close as possible to the book.

As you get good at Scrum, your inspections and adaptations may take you away from the book. When is that OK?

I have two tests for good changes to Scrum:

  1. Does it cause you to inspect and adapt more often than Scrum-by-the-book? If yes, it's probably a good change. If not, then probably not. 
  2. Is your change the result of an agreement, either among the Scrum Team or between the Team and its stakeholders, to improve performance? If yes, it's probably a good change. If not, i.e. you are accommodating some endemic problem or inability to change, then you are probably being tempted by the Dark Side and should tread cautiously. 

I think (1) is a stronger, more reliable test than (2). And I think if (1) and (2) both pass, well that's a sign of impending Awesomeness!

What's you take? When is it OK to change Scrum? How do you check that the change is OK?

Friday, August 15, 2014

Z is for Zukunftstag (#AgileFutureDay)

Agile is changing the world, but our schools are still preparing kids for the way world used to be. Would you like your kids to learn the ways of the future?

Thursday, November 13, 2014 is "Future Day" in Switzerland. Originally conceived as "Daughter's Day" to encourage fathers to take their daughters to work to experience non-traditional jobs for women,  it is now an annual opportunity for kids, usually in the 6th grade to get a day off from school so they can experience their parents at work and get a first taste of the real world.

My oldest attended one of my courses a few years ago (her insights were stunning, says the proud father) and this year, I will invite my youngest to attend.

Wouldn't it be cool if kids everywhere got a chance to experience the world of work, the way it should be? I'd like to call on trainers everywhere to invite the middle school aged children of their participants to join in their Agile, Lean or Scrum trainings on November 13th! Would that be cool? They can learn what collaboration can be! Let's make November 13th #AgileFutureDay!

P.S. I've got four spaces for kids on Future Day in my CSM course. No charge ;-)


Thursday, August 14, 2014

A is for Agile... and changing the world

We are uncovering better ways of developing software, by doing it and helping others to do it...

-- The Manifesto for Agile Software Development 

In 2001, seventeen people signed a 73 word statement that changed software development forever. Before: a bunch of guys doing "lightweight project management." After: a set of values which coalesced into a name, "Agile" and later into a movement. People identified with the values and transformed their working worlds with things like Scrum, Extreme Programming, Kanban, Lean Startup, and still other ideas and frameworks we haven't invented yet.

As we got better at developing software, we discovered the need for better ways at lot of things. The Agile movement inspired DevOps, which is looking for better ways to operate computer systems, and Stoos, which is looking for better ways of management. Soon, maybe scientists will look for better ways of conducting research, and maybe you will look for better ways of doing whatever you do.

How can you use the Agile Manifesto to help you? Start with the Agile Manifesto, find some colleagues who do what you do, and play with the Manifesto a bit. Not developing software? What is your essential goal or reason for being? Adjust the manifest as necessary to fit your situation. It probably won't need many changes.

So if you are in the HR department, what do you do? Maybe it is something like 'developing our human potential.' So what would a manifesto for agile human resources look like? Maybe something like this:

Sample Manifesto for Agile Human Development

We are uncovering better ways of developing human potential, by doing it and helping others to do it. Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Autonomy, mastery and purpose over documentation, directives and control
  • Collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
This is probably not quite right, but you get the idea. And it should be your manifesto, not mine, so feel free to keep working on it!

Want to change your world? Start looking for a better way! Maybe write your own manifesto... Want to find like-minded individuals, check out the Open Space event 24 Think Park in Zurich...




Friday, July 11, 2014

Can you recommend a virtual task board?

The participants of my last course had a lot of questions about working with distributed teams. What tools do you need to work with distributed teams?

I developed echobravo with a team from Brazil. As product owner, I was located (mostly) in Zurich. My team was in Maringa.

One aspect which encouraged the trust between myself and my supplier was the use of a cloud-based source code repository like bitbucket. Knowing that I had access to the source code in the event a dispute took a lot of the worry away from the collaboration.

We found "Web 2.0" tools like Google Docs, Google Hangout, Dropbox and Skype to be essential for collaboration. You can communicate with each other, share screens and access common files, e.g. definition of done. I liked Skype better than hangout for convenience, especially the ability easily recall old chats, but Google Hangout has better video and screen sharing (an extra cost feature on Skype).

In my experience, proprietary tools introduce cost which is a hurdle to using them, and more importantly, they introduce arguments over who will pay for them which can be an even bigger hurdle! Beware of proprietary video conference solutions. Make sure that it is possible for people to call in from home without proprietary hardware.

I find an online spreadsheet is an excellent, collaborative tool for distributed teams to maintain story maps and backlogs, and for holding a distributed retrospective. A wiki is also good for documenting stories, sprints, and acceptance criteria. You can also record the state of the task board every day by taking a picture and uploading it to the wiki, a capability which is, AFAIK, unmatched by any virtual task board.

I would only recommend a virtual task board if the development team is not co-located. (And I would not recommend a development team which is not co-located!). My Brazilian team and I used a Target Process to manage the backlog and the flow of stories (not tasks!) from waiting to working to done in the Sprint, but they used a physical task board to manage their actual tasks.

Target Process is dear to my heart for a number of nonfunctional reasons (ask me about "my" feature!). Greenhopper/Jira is quite widely used, because of its integration into the other Atlassian products, as are Rally and VersionOne. I don't have any strong preference for or against any of them. Most products have an online version which is free for five users, so you can try it out and figure it out before you actually pay money.

The main drawback of virtual tools are twofold: First, a virtual tool doesn't function well as an information radiator -- people have to actively look at the appropriate web page to see the status (if they even have access). With a physical board, anybody walking by can take look.

Second, Products must appeal to a wide spectrum of users, so they can do far more than you actually need. They often support practices which are not really recommended any more (like estimating tasks in hours). Wading through this excess can be confusing and cause you to waste time forever on unnecessary process.

I would therefore recommend, before you pick a product, start on paper. Then maybe move to an online spreadsheet. These are both very flexible tools. Figure out what your requirements and workflow really are. Then you are well positioned to pick a tool that suits you needs.

Thursday, July 10, 2014

XM Principle 10: Partner Patterns

Deliveries often rely on third party suppliers, and often they are not yet able to deliver a new product that meets our new specification within a single sprint. So what can we do in order to go from an idea to a new product or service in a customer’s hands in less than 7 days?

WIKISPEED first designs a wrapper, usually a plate of aluminum with pre-defined bolt patterns, around the third party supplied part to create a known “interface” that won’t change, even if that third party part changes. You might see how this is enforced by principle 2: Object-Oriented, Modular Architecture and 4: Contract-First Design, and then sped up by principle 6: Agile Hardware Design Patterns.

Once each third party part is wrapped in a known interface, you can iterate between suppliers and in-house prototypes or volume parts at very low cost. The only marginal cost is that of changing the wrapper itself.

Then, to expedite suppliers, ask them to deliver a certain set of performance characteristics as opposed to an engineering specification. "Do you have a transmission suitable for 100hp motor?", not "Here is our design for a transmission, can you build it?" Why should you wait months for a supplier to build a device to your specifications when they have a device that will satisfy your needs already in the catalog or in stock?

Many engineers are quick to design their own solution, which works to the team’s advantage when the design team is also the volume manufacturing team. But in cases where some production is outsourced, sending a list of values and tests to the outsourced vendor and not sending an engineering specification gives the supplier the most room to innovate. This allows the vendor to do what they do best, that part, which is why you are partnering with them in the first place. Team WIKISPEED finds they get higher quality parts faster, often from within the vendor’s existing stock.

The 10 Principles of Extreme Manufacturing

Wednesday, July 9, 2014

XM Principle 9: Scaling Patterns

XM scales as Scrum scales, by adding teams. Coordination can occur through the Product Owners, Scrum Masters or Team Members, depending on the scope of the issues involved.

When multiple teams work on the same module, they each own a sub-module, which will require another finer pass of Contract-First Design to create interfaces for sub-modules before those teams can be created. For example, within the engine module there is the fuel system module, the engine electronics module, the exhaust system module. Each module has an interface that loosely couples it the other modules and clear tests of their value and technical excellence.

Creating Teams

Applied at WIKISPEED, the first design decision is the fundamental architecture of the product being created, in their case a car. What are the main modules, e.g. engine, body, drive train, cockpit, etc., and what are the interfaces between them? Once the modules have been identified and the contacts between them created (see XM Principle 4: Contract-First Design), sub-teams can be created on each side of an interface to develop that module.

If capacity allows and velocity and quality metrics indicate adding more teams per module will improve velocity and quality, then multiple teams can work in parallel per module.

Each team owns their own integration and tests, no team is “done” with an increment of their module until all tests pass, including tests that it complies with their module’s interface and no additional connections have been introduced.

Team Coordination

In XM Scrum of Scrums, teams consist of 4 to 5 people, including a Product Owner and Scrum Master. Each product owner is responsible for pulling stories from the Portfolio Product Backlog (or simply "Backlog"), and getting clarity when their team needs it on the customer visible value and Net Present Value each story is intended to deliver.

This clarity comes from the Chief Product Owner (CPO) who sequences and refines the Portfolio Product Backlog continuously. The CPO is not a senior role in pay or experience, but is simply the person available enough to keep backlog ready for the teams, answer questions, and have the most clear understanding of the customer visible value the Portfolio Product Backlog is aiming to produce. Ideally, the CPO is the customer, and the one paying for the product or service the backlog is aiming to produce.

On each team, each Scrum Master is responsible for accelerating the velocity of the team, i.e. the amount of work sustainably delivered each sprint. Sustainible implies that the teams are happy and that all work completed satisfies the quality metric called the Definition of Done. Scrum Masters have an additional job here, too: they collaborate with the Scrum Masters of other teams to negotiate the shared resources like space, tools, and modules, across teams.

In this way, a team of 5 has clear expectations for themselves on how to resolve the most common types of impediments: lack of clarity is handled ASAP by the product owner, lack of backlog is handled ASAP by the product owner, lack of visibility into team delivery trend/quality/happiness is handled as a matter of course each week by the Scrum Master, and resource constraints and coordination are handled ASAP by the Scrum Master."

Next: XM Principle 10: Partner Patterns

The 10 Principles of Extreme Manufacturing