New Generation Scrum

Scrum has been around long enough to be considered a mainstream project control methodology.

Companies that have successfully adopted Scrum have prospered. And a lot of companies, ours included, have attempted to make money by providing tools to help with adoption and use of Scrum.

As with all other areas of human endeavor, Scrum is being analysed and probed. Some people are suggesting changes; either small and still calling it Scrum, or large and calling it something else.

I particularly like some of the suggestions in proposals like Scrum-ban and I’ll come back to the reasons why later.

Other people create proposals and change the name completely; just today someone suggested I create a new acronym. About as far as I’ll go are the ‘scrumptious’ workshops I’ve run.

Although these other ‘improvements’ or suggestions threaten to splinter Scrum, it’s the tools that I think are the biggest threat to the growth of Scrum.

And that’s a paradox. Tools are designed to make a job easier, right? Not in the agile world. Let me point out the first line of the Agile Manifesto, which is:

Individuals and interactions over processes and tools

My opinion is that anything that takes away the power of individuals in a Scrum project to change the way they do things is taking away from the essence of Scrum. Even the act of accumulating and documenting best practices can end up being used by traditional project managers as ‘the way we do things around here’. These best practice can turn into worst practices if the environment changes. Change is inevitable, and that’s the fourth line of the manifesto :

Responding to change over following a plan

Recent discussions suggest that Scrum, like several other agile control methodologies is not actually a methodology, but a framework. It’s the ‘introspection’ that is important.

In the discussion the article by Esko Kilpi is highlighted. Esko makes it even more clear.

Interactions are important. If we are to deliver software to the customer (the second and third lines of the Agile Manifesto ) with a team then the team must interact.

We need to go back to the Scrum basics and bear in mind the Agile Manifesto.

And that’s the reason I liked some of the things in Scrum-ban. It’s not modifying the essence of Scrum; the major players are present, and there is still a cadence even though it is overlapping. It’s the use of the Kanban chart to aid in interactions that attracted me.

The phrase Information Radiators is used to describe these things.

I call them big boards. Big White Boards that everyone can see, all the time.

Big boards are an essential part of the team and no tool, even though it fosters distributed development, can replace them.

So, New Generation Scrum is actually a Back To Basics Scrum.

---

Will you cope?

We speak to a lot of companies that do software development as part of their products.

In fact most modern products will have software either in it or driving it.

If you are creating innovative products you need to get them ready for customers very quickly. You may be able to cope with just one or two customers. Will you be able to cope if several prospects ask for variants of your product?

ScrumIT can help.

Our experience using Scrum project control is that, with a small team (2-3 programmers), most projects can have the majority of the needed functionality completed within six weeks. We use two week sprints and we have found that only three are needed to produce most of what is needed.

You (and your customers) get to see two demonstrations of working software. With your vision close to realisation you see clearly what you need to deliver.

We know that a lot of functionality a customer wants turns out not to be needed.

With Scrum based development you pay for what you need.

You see, it’s the difference between want and need. When you do traditional software development you produce a specification. You tend to throw in everything you want, including the kitchen sink.

Specifications tend to be complete, crossing all the Ts and dotting the Is. They’re used as part of the contract.

With Scrum control, you only ever commit to the next two-week sprint. If you’re not getting the expected return on investment, you stop.

So, with orders coming flooding in, you don’t want to take on extra staff to write up the specifications, contract programmers to do the coding and then extra managers. That will absorb extra resources just getting them in place and training them up.

Work Smarter, use Scrum. Use us to manage your programmers, teach them Scrum, work with them and you and your customers.

---

How does scrum help hardware design

Once again we visited a group to explain what we are trying to do with Scrum IT. This time in Holland .

I talked with one company and explained that, even though they are analogue hardware designers, their hardware will be driven by software. To supply hardware without regard to how it will be used is missing a trick. In this specific case we agreed that the hardware had some software control.

The designers had created a board with their chip on it, and considered it research. However they didn’t want to supply it to customers, just show it to them. The aim was to engage the customer in consulting to create a specific hardware design for them.

I’ll come back to this, after I explain the other discussion.

I was asked specifically how Scrum can be used with hardware. This is simple, Scrum is a project control methodology. It’s become popular in Software. In it’s earlier guise as Sashimi, it was used for general product development. Here is a PDF of the original paper .

Wikipedia also explains the history of Scrum as a general project control methodology .

If you put a team together that includes the hardware designers and the software developers each customer feature benefits from at least two viewpoints. Put a web designer, graphic artist, technical author in the team and the user documentation comes out right, too.

Most product features cross the boundary between hardware and software, even when the software is purely for diagnostic or maintenance purposes. That boundary can be discussed by the hardware and software engineers who have a common aim. That common aim is to deliver the best return on investment to the customer. The customer has been in the sprint planning meeting and has agreed what the team will deliver at the end of the sprint.

If for example some hardware can be made cheaper by removing a FIFO and doing the buffering in software it is the engineers who can decide this as they are implementing the feature. If the reverse is true and performance can be improved by using the FIFO, again it’s the engineers who can decide. They have listened to the customer and they know what the customer is prepared to pay for; cost or performance.

So, let’s get back to the first company. The one that didn’t want to get involved in software. What they could do is supply an early evaluation system to as many customers as possible, at cost price. They want to get as many customers as possible, or rather want as many happy customers as possible. So they should give prospective customers the means to think about the research project without having to engage fully with the designers. To do that three short scrum sprints could be done, with the hardware and software engineers. Like this.

three scrum sprints

What are these Ss? If you have looked at the scrum methodology you’ll see there are two interlocking cycles. There is a diagram at the main scrum website and at the wikipedia site referenced above. ScrumIT even has it’s own PDF version you can download and print out – SCRUMPoster.pdf . So the Ss represent a single sprint to develop working functionality.

The aim is to supply an early evaluator to customers. The chip designers supply a board and some software that would run on a PC. The evaluation kit has cost very little to produce; the board layout and possibly six weeks of software development. The boards are supplied to customers at cost. Invariably these customers want it to do other things; perhaps they want it to be integrated with their own software or hardware. They could do another sprint to add the functionality.

If three customers each carry out an increment on the basic demonstration, there are now three variants of the evaluator. All of them work. Scrum delivers working features, not demo or dummy features.

three sprints and three customer sprints

Now the designer has access to extra functionality they could wrap up into the product and make it more attractive. They could do one final increment of the software. It would probably satisfy most of the customers who wished to evaluate the hardware.

From demonstration to dev kit, refining the hardware and software at the same time and engaging with three customers. All done in possibly as little as two months.

Scrum is hyperproductive. It also works with multidisciplinary teams.

---

Scrum for general projects

Scrum can be used for any project.

There are a couple of problems. Someone else has seen this and they posted on their web site .

I’ve discussed this with various people and tried it with a couple of projects. We use scrum with another technology; Getting Things Done. People know that I’ll ask about next actions in meetings.

I won’t make this long and drawn out. I modified the GTD flow chart to allow it to work in a scrum environment. It’s a simple change to work with a team. Here it is.

Scrum and GTD

---

Incremental design

How does Scrum cope with design?

I got asked that a couple of times last week . So this is an answer that I can point to in future.

Let’s get some ground rules out of the way. Some definitions.

Design is solving problems in the defined solution domain. Here’s a list of domains:

  • hardware,
  • software,
  • systems,
  • integration,
  • network,
  • processes,
  • training.

Architecture opens up the domain to areas that your design doesn’t go. For example regulatory, environmental and ethical considerations. You don’t design in those domains, you consider them. They are part of the overall architectural vision.

So, bearing in mind that I’m referencing other writers here, they may use the terms design and architecture in different ways from me.

The Scrum world talks about ‘horizon’ when it looks at features. If something is over the horizon then you don’t need to spend too much time on it. The requirement goes on the backlog and will be discussed by the team when it gets closer.

That worries people. Does that mean the design is short sighted?

Perhaps it does, but who is to say that a design that is ‘grown’ as features are implemented rather than ‘planned’ by months of theoretical work is less coherent, or less appropriate?

The important point about scrum is that it doesn’t concern itself with how something is implemented; that’s up to the team.

Scrum is about keeping track of any project so carefully, with such an eagle eye, that any delay, any backlog, gets the immediate attention it deserves. In a smoothly running project, the first delay is the most important.

Let’s get back to design. This is more an agile development issue, however it is related to controlling a project.

It’s important to allay people’s fears that they are getting a ‘less good’ product if they don’t take great care in the initial design of their product; if they leave the team to ‘Just F***ing Do It’ (JFDI).

The article I always cite is by Martin Fowler, chief scientist at Thoughtworks . It’s called ‘Is Design Dead?’ and the basic premise is that design can be incremental, if sufficient tests cover all the parts that may change when a new feature is added.

That means test driven development goes hand in hand with incremental design. You cannot use incremental design as an excuse for less work. You take the hit on having tests for every function in your design. And more.

Today I found another reference; it’s a video at the server side . It is an hour long and haven’t watched it yet, when I have, I may update this posting.

---

« Older