Do something S.P.E.C.I.A.L.!

Scrum – Start sprinting, there is no faster way to fail and then correct the problems and then do it again to achieve continuous improvement.

Positive – You have to maintain a positive attitude. Accepting change isn’t easy for most people and there will be some that may find it difficult to adapt. Learn enough to be able to explain a lot but also continue reading and finding answers as you go.

Effort – you need to make an effort to make this work, and not only you. Everyone on the team must get out of their comfort zones and start thinking on how to improve every single detail of what they do. Many Scrum books recommend as a prerequisite having the right people and the right people must have the right attitude and be able to make that extra effort to succeed.

Communicate – communication is a key factor in the success of every agile transformation. Make sure you remove all barriers that may prevent communication. These could range from cubicles to avoiding conflict. You may need to learn a lot about dysfunctions and how to cure them and you may need to participate in difficult discussions with facilities managers. But without doing it you will be reducing your chances to succeed.

Inspect – regularly look back and think about the things that you did well and the things that you have to improve. Find a good retrospective technique that works for your team and make sure you look not only within the team but also for organizational barriers.

Adapt – identifying the issues would not be worth the effort if you’re not doing enough to resolve them. Things that slow you down should always be near the top of the list for stuff you need to do. Add them to your backlog and make them visible – this is an effective way to get them resolve and then identify more issues.

Learn and listen. Never stop learning, learn from mistakes, from the experience of others, from the people you coach and teach. Learning, just like improvement, never stops. Learn to listen, because the moment you started this transformation you’ve become destined to coach and coaching is all about listening and asking the right questions to help people around you do better.

Are you ready to do something S.P.E.C.I.A.L.?

Effective coaching styles

Open space session notes from the Agile Coaches Gathering 2009 (Milton Keynes)
Key info:
- Facilitated by Xavier Quesada Allue
- Attendees that I remember: Rachel Davis, Manish Shah, Bob Marshal, David Draper, David Joyce, Manav Mehan (and many more + I hope all these guys really were there)

First we listed styles that we can think of including:
- Non directive style
- Leadership style
- Depending on what the person expects (adaptive)
- Trainer style
We recognized the fact that there are dimensions and styles. We looked at established coaching models like GROW (Goal, Reality, Options, Will), The Dreifuss model, The solution focus model based on getting the goals out of the coachee.

Then we talked about capability coaching and the thoughts I listed on this were various approaches and questions to ask like:
- Interesting! Tell me more? (instead of reacting negatively and directing)
- Why? – Perhaps replace with “what would that give you?” or “what would that result in?”
- What value does that give us? Is that what we want?
- Get going (not sure about this one, perhaps related to do and then inspect.)
- Look at all the issues (e.g. impediments, problems) and prioritize – perhaps phrase this as question

Somebody asked the question – Do you have to have all the styles? And the answer came that you certainly need a set of styles. How do you find out how effective your style is? Watch other people coach in action (Shadowing; Pair-coaching).

You need to ask yourself the questions – Who you are being and what you’re doing. You can have the same or different model and perhaps slightly different style.
You may want to think about 3 adjectives that you would use to describe this person like best at? Or worst at?

How to find out if you’re effective? Can remote coaching be effective? You rely on hearing only and lose the body language. Near coach/far coach model.

Coaches should not be part of the system – if you are then you’re missing coaching opportunities. Your goal as a coach should be the improvement of the team.

The team must respect you. You have to be visibly doing stuff. If you quickly show/add a bit of value then you get respect. You also need to show respect. Consider if the team has actually asked for a coach?
[An interesting related book is “The speed of trust”]
There are 3 factors:
- Character
- Competence (It has been noted that it is easier to coach if you’re less competent as you do not direct)
- Consistency (develops over time and sets predictable behaviour)

For example coaching a tester can be effective even though you don’t know anything about testing.
You perhaps need some basics – e.g. TDD, principles, knowing concepts and tools.

Coaching is to help someone move forward.

[A good book to check is Quiet Leadership.]

Value, Flow, Waste

I heard somebody talking about these three in the same sentence a couple of weeks ago and accidentally (or perhaps now) used them in a presentation draft while trying to explain what in Scrum we'd separate as functional/non-functional.. and waste although it doesn't seem to come up that often as the other two.
Anyway so I had to explain what it is as the word Value seem to be causing hiccups with some of our managers and the shorter explanation I could think of was that value is what we get money for, flow is what makes possible the production of value and waste is all that doesn't add to any of the other two so we throw it away.

I then ended up searching for more info and discovered 5 principles of lean (as opposed to the more famous 7). Here they are:

1. Specify value
2. Identify the value stream
3. Make value flow
4. Let customers pull
5. Pursue perfection (e.g. identify waste and eliminate continuously)

Ok, so the connection is that these 5 principles well explain the title as well and I am going to use them when I talk about it in about 10 days time. I may even post something about the event as it is my first ever agile project initiation boot camp.

MCIF or beware - IBM now wants to make money out of agile!

After the big guys realised there is no way RUP can deliver as well as what can be described as naturally evolved and community driven agile frameworks like Scrum and XP they now seem to have decided that at least they can save their reputation by switching to agile but they also want to make money by using the equivalent of open source development approach.

I feel really sorry for the people that will spend money on this just because it comes from ibm. As before they'll stick with it for a while until the community moves forward and discovers something better. then ibm will go away and come back with another "clever" abbreviation.

Do not spend big on agile transformations. money will not give you productivity, not from such big companies anyway. speak to people in the community and you'll soon get a good recomendation of a successful coach or even a consultancy. As for IBM - yeah good luck with that.. I predict another RUP-like story...

Unit Testing ASP.NET? ASP.NET unit testing

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

South UK Scrum User Group, 27th April 2009

Getting an acceptable definition of done

[Notes from 27th April 2009, South UK Scrum User Group]
The level of granularity is important, which is why we define the definition of done at four levels: release, sprint, story and task.
At the task level we look at the following:
- Developer says it is done
- Unit test exists and passes
- The code is in the trunk
- Code coverage is above the target (e.g. 90%)
- More criteria can be used as function points, analysis coverage, cop type coverage
- Tracking system is updated
- Check-in is reviewed
- The work is reviewed
At the sprint level we define the following:
- All agreed stories are done
- Held a retrospective which is documented
- Show and tell demo
At the Release level the criteria are:
- All sprints are done
- Media is produced (e.g. CDs, marketing materials)
- User documentation has been reviewed (e.g. by the user community)
- Install and release notes are ready
- External testing or audits are performed (e.g. security audits)
- PO signs it off
The definition of done for Story include:
- All tasks associated with the story are done
- The story is integrated and tested
- Acceptance criteria is met
- Installation works
- Documentation is done
- Product owner accepts the story

First UK South Scrum User Group Notes

On 18th this months in a nice pub in Ringwood we had the first ever UK South Scrum User group meeting.

I tried to take as many notes as possible for the benefit of the group members and hopefully the entire Scrum community.

Here's what I managed to write down:

What do we want to achieve with this group?
- Get people to come along and chat (about Scrum and Agile)
- Meet once a month every 3rd Tuesday (this has not changed to last Monday of the month)
- Talk about common issues and ways to resolve them
How do we do it?
We will experiment and pick one of the following or perhaps something else if these are not suitable:
- Open space discussions
- Goldfish bowl
- World cafe
How do we make people aware about this group?
- Ask people who do training for contacts
- Blog about it
- Announce it to NextGen members
- Make it regular – regular day and location
How big do we want it to be? The bigger it is the more structured it has to be.
- Could have perhaps a “learn about Scrum” session
- Talk to big Scrum/Agile consultancies like Conchango/EMC or RallyDev about sending speakers.
- Clive and Plamen to talk with Roman on 8th April (London Scrum User Group) about getting the group listed on the Scrum Alliance website.
We then talked about the biggest challenges that each of us recognises. I have recorded hopefully most of these:
- Getting acceptable definition of done – everyone to sign up for it [This has also become the topic of our next meeting on 27th April)
- Guiding/Coaching ScrumMasters that are new to Scrum and making them become Scrum advocates
- Getting full Senior Management support in a big organisation
- Change process as a whole and trying to implement it into large organisations
- Requirements – getting the definition of them, making them agile requirements.
- Technical gold plating – when to do just enough architecture, design ,etc.
We then went on to talk about positive experiences and again I hope I recorded most of them:
- Team refused to estimate as no answers were given to important requirements questions
- Team no longer delivers the wrong solution
- Team response to HR attempt to impose individual performance reviews.
- Team managed to isolate maintenance to overcome problems with delivering
- The “War room” and winning it from the business just for Scrum use by the teams
- Throwing away the concept of in-sprint defects and no longer wasting time to log them into some system. Get the testers talking rather than typing.
Other thoughts or discussions were around:
- Getting people to understand what is realistically done and optimistically done
- Tech authors could be key as while wanting to know more they lead the information sharing and steer teams towards delivering the user stories
- Important thing is to have the right ratio QA/Developers
- Tools in use include: Rally, TFS, Version One, Target Process (also has helpdesk) and xProcess.

Overall a very good evening and lots of ideas have been discussed. We also managed to set up date for the next meeting, agree on actions about making people aware about the group and identified the main topic for next time.

I hope to see you all there and hopefully a few more people will turn up as well!

Scrum User Group in the South (outside London)

A fellow scrummer based in dorset has posted this yesterday and emailed the scrum development yahoo group with an idea to organise Scrum UG in close proximity to BH, SO, PO. I then decided to join him in an attempt to gather enough people and created this linked in group. If you happen to somehow find this post and live in the area and are interested in participating in a Scrum UG please join the linked in group.

Ron Jeffries answering 5 Scrum questions

I always enjoy reading Ron Jeffries' posts and they are one of the reasons for me to subscribe to as many agile yahoo mail groups as my mailbox is comfortable with.
So when I found, this short interview I thought it is brilliant, just like reading about 10 posts at once which usually means lots to learn from a great agilist in just a few minutes of reading.

Въведение в Скръм (IntroToScrum) на Български е публикувана!

След много дълго продължил превод и доста по-бързо направени ревюта от:
проф. Аврам Ескенази
и
Георги Стойчев
успях да направя корекциите и изпратих първия вариант на презентацията която Майк публикува вчера на този адрес.

Междувременно се оказа че има още желаещи да помогнат с подобряването на превода така че скоро ще има обновена версия.

Много се надявам това да се окаже полезно и да допренесе за популяризиарнето на гъвкавите методи и в частност Скръм в България.

П.С. Това ми е и първият постинг на Български ;)