Agile Lab - Training, Coaching and Consultancy

Wednesday, 28 October 2009

Very Pleased (Again)

Just finished the sprint planning and review meeting. It was another blinder. We identified more problems and R [project manager] came up with a really good idea to solve one of them.
All's good... your help has been really fantastic in improving our team's process, reducing stress and making visible where we're losing profit and morale so we can improve even more in the future.

Rachel Collinson - from http://www.rechord.com/


For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , , ,

Tuesday, 20 October 2009

Notes on Value from worskhop 14/10/09 - Building the Lean Web Development Team

Notes from my Beta Workshop - "Building the Lean Web Development Team".

We talked about four general areas on Wednesday:

  • Values
  • Flow
  • What is it?
  • Poke Yoka

Values

When we talked about Values we said that one of the important aspects of the Toyota Production System.

The Toyota Production System insists on seeing the world of business as a value-stream. Each activity in the value stream either adds value, or it doesn't. If it doesn't, it is a candidate for removal and reduction. The way to identify these candidates is to create a value stream map of your organisation (this is very similar to a "Brown Paper Exercise" done by many management consultants). We did this in the class and this is what we came up with:

We then highlighted the areas that we thought were adding value in the process [in red]. Then we highlighted the areas that we didn't think added value to the process. Quite a few of these were activities to do with planning and assessing the work that came in. The very radical idea occurred to us - "What if we didn't do those bits?" What if we just "Exposed our development capacity" to our clients - this brings in some of the Kanban thinking - "here are the slots, it's obvious when we're available and when we aren't." How do we figure out whether we can do a piece of work or not? By trying to do it.

When you look at things in this way, planning and estimation look really pointless. If your capacity is really obvious, then the option of figuring out how long something will take by trying it presents itself.

What are our values? I used an activity that I'd learned from reading "Sources of Power" by Gary Klein to come up with a bunch of values for the group. We wrote these on a set of index cards.

Web Developers' Values

  • Software engineering best practice
  • Customizable
  • We're a learning company
  • New People
  • Good solutions in non-perfect situations
  • Dealt with unexpected problems
  • Customer delighted
  • Generic
  • Flexible Code
  • Speed
  • Setting an example to other developers
  • Adding structure
  • Product
  • New challenge
  • Taking a risk

We then asked if these were the values of our customers, or our suppliers?

Customer's Values

We thought our customer's values were probably very different - this is the list that we came up with:

  • Easy Life
  • Shiny Fun Web
  • Rounded Corners
  • Blue
  • Verdana
  • On-Time
  • To-Budget
  • Free Food
  • Good Coffee
  • Regular Updates
  • Non-Threatening
  • Lack of Jargon
  • Learning Jargon to impress Boss

Who are your suppliers?

I'd talked to some of the people who turned up at the course - a woman who owned her own web development business and she'd told me with a shrug that she didn't really have any suppliers. After thinking about it for a while, I realised that this was very wrong. One of the things that Toyota does that makes it very different from other companies is that it has very involved, very long-term relationships with its suppliers. Here are some suppliers that you have that you might not have thought of:

  • Universities (supply you with staff). Universities supply you with staff. Are the universities teaching their students the kind of things that you need them to know? Are the universities picking the right kind of people to come on their courses - are they a good "fit" with the organisation. We talked about the value of having interns - I asked if anybody had ever had interns and there was a general agreement that when they do have interns, they're given "grunt work" rather than anything that might allow them to learn, or show off their abilities.
  • Other Web development companies (supply you with staff). People come to you from these companies - the better you know them, the better chance you have of good people coming to you from them.
  • Software manufacturers (Apple, Microsoft and Adobe)
  • Hosting. I hear lots, I mean LOTS of stories about last minute changes to hosting requirements that come from a client and derail a project. Do you have a really good relationship with your hosting supplier? Alternatively, are you permanently chasing problems with a very cheap hosting supplier?
  • Me, and people like me (I supply you with training and consultancy). How do you make sure that I know enough about your company to do my job properly. What sort of experience and abilities do you need in a consultant?

Value Dynamics

What are you supplier's values? How do they change throughout a project? This seems to be a crucial part of the business of web development in a way that it isn't in other industries such as car manufacture where buying the product is a quick process rather than the long, drawn out process that it can be with web development. I think a lot more work needs to be done on this, but for now, what we came up with was as follows:

Beginning of a project: What's important to customers at the beginning of a project is price and feature list, and impressive pitches.

Middle of a project: What's important to customers in the middle of a project is understanding the trade-off between features and price (although this sounds like a web developer-view to me).

End of a project: At the end of a project there are a whole different bunch of things that are now on the client's mind. Now they need to be able to show some working software to their bosses, and also, possibly some return on investment (ROI). We all agreed that if there is working software that is generating value, then the budget is much less of an issue.

For further information, contact mark@agilelab.co.uk (07736 807 604)

Labels: , ,

Friday, 16 October 2009

Books that I talked about on "Building the Lean Web Development Team" 14/10/09

This is a list of the books that I talked about on the "Beta" course I ran in Bristol on 14/10/09. I'm writing this list out so that I can send it to the attendees, but I also thought it would be good to share it here.

The Machine That Changed The World




This is the book that started off my investigations into Lean and it's well worth a read, even though, I think Womack and Jones, who've gone on to write several further books, have changed their thinking a lot since they wrote this.

The thing I particularly like about it is the unimpressed view of western manufacturing from a Japanese perspective.

Taiichi Ohno, the Toyota Production System



The grandaddy. The dude.

I'm wary of treating any book as a hallowed text, but there's a lot of interesting stuff in this one. Even more interesting than the specific content is the approach. It take vision to look at the huge success of Ford's mass production system and say "Naw, we're not going to do that, we're going to do something different."

One way of thinking about Lean approaches is that they are a process of "Learning to See", another is that progress comes through continually looking at what you are doing and asking "What is it? What is it?". I think Taiichi Ohno might have been one of the few people ever who really understood what a car factory was.

Lean Thinking: Banish Waste and Create Wealth in Your Corporation



This is a later book from Womack and Jones with detailed case studies of several companies that have adopted Lean methods in order to improve their performance, including Porsche.

Zero Quality Control: Source Inspection and the Poka-Yoke System



Again, the main benefit of the thinking in this book is its difference in approach. This time to catching and fixing mistakes, not by yelling at staff to be better, but by working to improve the system.

Mary and Tom Poppendieck: Lean Software Development, an Agile Toolkit



I haven't yet read this all the way through, but it looks very good. The only issue that I have with it is that it's software oriented, and part of the point of the course yesterday was to question whether web development is actually software-oriented, or actually something entirely, or considerably different.

Martin Fowler: Re-factoring - Improving the Design of Existing Code.



A good book to look at when you're trying to think of Poka Yoke methods to mistake-proof your operations.

Gary Klein, Sources of Power.



Used this as a source for a value-generation exercise that we did: got people to tell stories about their expertise.




For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , ,

All the Written Feedback from "Building the Lean Web Development Team" in Bristol 14/10/09

Negative/Could do Better

  • Would like some of the examples that string it all together.  To summarise learning.  Maybe there is a good one in the books.
  • Always nice to have an agenda at the beginning.
  • Is there anything else that is diagrammable?
  • Not sure how useful the 'What is it like? What is it not like?  exercise was.
  • Attendees should come from a cross-section of an organisation.
  • More discussion needed on value dynamic, and on suppliers.  I'm not sure I'm getting it yet (I know they are different issues).
  • Feel slightly overwhelmed.
  • Would be good to hear about a team who are doing this... how you might see this working.
  • Next steps are big risks to take - help!
  • Have more questions now than answers - maybe this is an unrealistic expectation because nobody has done this before.
  • Not sure of the relevance of the "What is web dev like or not like?" section.  Maybe some poignant note with summaries of your points would be helpful.
  • I am unsure whether the point you made about roles required in a web dev team was actually answered.  So was there a point?

Good Points

  • The diagram of flow was really handy, sound.  That made lots of sense.
  • Liked all of the activities, especially like the mind-clearing ones.
  • Showed the importance of thinking outside your own values system.
  • Nice selection of further reading to think about.
  • Easily accessible course.
  • Been thinking about a few of these things before the training - good to hear it from a professional experienced guy though.
  • It's good to have a few people to get tailored adviced.
  • I like the method of teaching where you encourage students to come up with the answer themselves.
  • Some good practical steps sections where we learnt how to apply to our organisation.
  • Great to learn about processes that we can directly take away and apply practically to our own companies.
  • Definitely going to promote the idea of rewarding quick sign-off.
  • I like your analogies.  They help me understand the concepts and how they relate to my business.
  • Chance to talk about things with other people in a similar situation.
  • Value Dynamic.
  • Practical things to try out, if my staff can cope :-)
  • Mark's experience of working with difference web agencies.
  • Great ideas, inspiring possibilities
  • Value chain exercise
  • Interactive bits

 


For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , , ,

Thursday, 8 October 2009

Do you speak organisation?

Having gone to Andy Murray's Prince2 refresh talk at the BCS, I'm starting to think that the issue between Prince2 and Agile might be slightly more subtle than I thought. Prince2 is a method of talking to organisations.  Agile is a set of methods for delivery, especially for software.  Both methods claim to be able to do the job of the other.  Both are bluffing.

Yeah right, I know, Scrum of Scrums.

Also, as far as I can see (my knowledge of Prince2 is very sketchy) there's nothing in the method to say how you actually get the work done, so what's to stop prioritised lists, Kanban-style displays of work in progress and strict limits to how much of that work is in progress?  I think this is what the guys at e2x were trying to tell me last time I talked to them, but I wasn't ready to get it.

Maybe Prince2 is a bit like Old Entish. Maybe arguments between Agilistas and the gentlemen of Prince2 is a bit like the battle between materialists and idealists in philosophy of mind.


For further information, contact mark@agilelab.co.uk (07736 807 604)

Labels: , , , , , ,

Friday, 2 October 2009

Where is the "foo-whiffle file?"

Once you get a source code management system, make sure it is the well known place for everyone to go get source code. Nobody should ever ask "where is the foo-whiffle file?" Everything should be in the repository.

http://www.martinfowler.com/articles/continuousIntegration.html

Posted via email from What Stringer's Reading

Martin Fowler on Continuous Integration

When I've described this practice to people, I commonly find two reactions: "it can't work (here)" and "doing it won't make much difference". What people find out as they try it is that it's much easier than it sounds, and that it makes a huge difference to development. Thus the third common reaction is "yes we do that - how could you live without it?"

http://www.martinfowler.com/articles/continuousIntegration.html
--
http://www.agile-lab.co.uk/          http://twitter.com/Mark_Stringer          07736 807 604
I'm not as other Agile Trainers - proof?  Read my blog:  http://bit.ly/8DKd9

Posted via email from What Stringer's Reading