Simple win #1 Daily meetings

Irrespective of the project methodology, doesn’t it make sense for people to regularly get together to agree on project progress and to identify and address issues as early as possible? Daily stand-ups/meetings allow the team to assemble and check that the project and individuals are all still aligned without consuming significant time. Try the following simple technique by gathering the team together once a day:

Each person in the team has 1 minute or less to describe:

  • What did they do in the last working day?
  • What do they plan to do in the next/current working day?
  • What obstacles are preventing them from achieving their deliverables?

By answering these questions the team focus on their tasks and also those of the rest of the team. This helps ensure that analysts, developers and testers know when to expect deliverables and ensures they realise that other people are waiting on them.

To be effective these meetings should occur at the same time everyday at a time which is convenient for all. To ensure promptness you might like to ask the last person in to start. If someone cannot make the meeting then it should still happen. Ideally you’re looking for the meetings to become like clock work.

The time of the meeting will obviously depend on when the meetings are held. I typically like holding them first thing – at a time when everyone is in – at the same time everyday at a time which is convenient for all. If the team is geographically distributed then timing becomes trickier as does ensuring that everyone can hear each other – crackly, quiet phone lines aren’t optimal although skype is usually useful and cheap. If international calls are barred there are cheap national numbers which allow you to dial internationally for a minimal cost.

You can also let stakeholders know what is being worked on so they can listen in. If they have any questions they can grab the relevant people after the meeting, rather than hold the entire team up.

Give it a try.

What’s in a name?

Sometimes when I’m introducing Agile to a company I wonder how seriously people are taking me when I use terms such as kanban, Scrum, dojo etc. I also become frustrated when I hear someone state they are adopting Agile and I reply by asking which methodology and receive a response along the lines of – “erm, err, just Agile”. A long time ago I used to be a member of the SUN advisory board meeting regularly to discuss SUNs strategy. During these meetings I’d often advise against the use of martial art “belts” to indicate an individual’s ability as it just didn’t appear professional compared to my engineering background. I’ve also worked with a company to deliver a “factory” model and this suffered from highly technical people being insulted by the connotations of unskilled workforces performing mind numbing tasks. The Agile term is strictly forbidden. All this got me thinking:

Shouldn’t we stop hiding behind buzzwords and instead ensure we’re just focusing on delivering best practise?

Agile Myths

Image

Having assisted numerous companies with adopting Agile I’ve heard a lot of concerns and myths. I’m always surprised how many times I hear the same myths quoted as facts and thought I should share my thoughts:


Myth: Implementing Agile is easy
Truth: Agile does have some basic concepts but implementing it properly and making it self maintaining requires analysis, effort, a mindset shift and absolutely everyone needs to be bought in.


Myth: Agile gives instant benefit
Truth: Benefits are often possible in the short term but be prepared for a certain amount of disruption and effort aligning to any new process.


Myth: Agile means no documentation
Truth: This one actually frustrates me the most. The Agile manifesto states “Working software over comprehensive documentation”. This means focus on working software but do not ignore documentation. Be extremely wary of anyone that states otherwise!


Myth: Agile means ‘hacking’
Truth: Agile encourages prototyping and early development but this needs to be aligned with the solution, testing and the customer. Just “hacking” is not going to deliver working software in an efficient manner.


Myth: Agile means poor quality
Truth: This is another frustrating quote. Agile is about building quality in from the start not about catching it late. Quality level needs to be confirmed and adhered to right from the start.


Myth: Agile is a silver bullet
Truth: Agile offers common sense benefits but it can’t solve everything alone. It still requires effort, analysis and alignment.


Myth: Agile is easy. We can just read a book
Truth: I’ve been asked into a few companies where they have used consultants or internal staff who have simply read a book on the subject. This can provide benefit but I tend to find that they miss the mindset shift of what Agile is about and therefore miss at least 50% of the benefit.


Myth: Agile is new/just a fad
Truth: One can argue that Ford in 1910 and Toyota in 1940 were the earliest form of Lean development. Agile is just about best practise so it can’t be a fad.


Myth: Traditional delivery never works
Truth: Some projects need to deliver against specific deliverables which are locked down at the start and must not change. In this case you may be better off with waterfall.


Myth: Agile replaces everything that has gone before
Truth: Agile learns from everything that has gone before by identifying best practise which delivers.


Myth: Agile means no planning – “Just do it”.
Truth: Agile prevents analysis paralysis and planning with unknowns but focusing on the immediate deliverables. These deliverables need to be clear and agreed or they will not be accepted.


Myth: Agile doesn’t support Jnr members
Truth: I would always favour a small group of highly talented individuals but we need to bring new people on and some tasks would better suit Junior members of staff. Just ensure they have the tools to do the work and they are supported and trusted.


Myth: Agile = Scrum.
Truth: There are many types of Agile. Scrum is just one. Each company should look at the different types (e.g. XP, DSDM..) and choose whatever works for them.

Agile introduction

I need to declare full disclosure up front, if you were to cut me open you would find Agile written through me like a slightly overweight, middle aged piece of seaside rock (hopefully this reference won’t be lost on my non UK readers). With this in mind my early years as a developer were spent frustrated that projects were taking too long, test were engaged too late and the business weren’t engaged at all. I appreciated that a process was critical and we needed to agree what we were to deliver and provide checks against progress but did it really need to take so long and be so disjointed? Over the years I learnt more about the classic problems with large “big bang” (aka waterfall) releases:

  •  In the numerous months between the customer requesting work and receiving it, their requirements had changed due to the speed of change in the real world. This wasn’t the client’s fault they couldn’t have predicted the next 6+ months with perfect accuracy.
  • During this time customers often had very little progress updates and if they did the indicators weren’t always reliable.
  • Dev felt they were too remote from the customer and feared making decisions or had to wait a long time for them to be made.
  • Test acted as game keepers trying to catch the developers out to settle the age old question of who’s better, developers or testers.
  • With a long project plan very little pressure existed at the start. Issues were found and added given the lack of pressure to hit deadlines. Panic only set in towards the end where it became clear that we wouldn’t achieve what had been committed to. We then had the choice of reducing the test duration or dropping functionality and sometimes both.
  • Often things would go wrong and it felt like some people were spending more time building their defence as to why it wasn’t their fault rather than working on a solution

You can therefore imagine my absolute joy when I was introduced to Agile. Oddly it wasn’t alien but simply collected ideas that I had seen working well on previous projects. I need to be clear that there are a number of Agile methods which we’ll be looking at in later discussions but for now a few forgive me a few generalisations. Agile focuses on:

  • Satisfying the customer through early and continuous delivery of valuable software rather than waiting till all deliverables are completed.
  • Work is performed in regular “chunks” or iterations and working software is the primary measure of progress.
  • Business people, developers, testers and analysts work together throughout the project to ensure the project remains valid and provides useful software.
  • Teams are given the environments and support they need to get the job done.
  • The team performing the work are involved with providing consistent estimates to divide the work into iterations.
  • Requirements are captured up front but we only add detail to the ones we’re due to work on in the immediate future.
  • The team are empowered to make the right decisions
  • Quality and validation are built into the process not an afterthought waiting to strike
  • The most efficient and effective method of conveying information to and within a development team is face to face conversation.
  • Any changes to requirements can be supported as long as we all agree and the impact is agreed.
  • At regular intervals the team reflects on how to become more effective, then tunes and adjusts accordingly.

Let’s be clear that Agile is not a silver bullet and won’t be appropriate for all scenarios but now that I’ve given a brief reason to consider Agile my next blogs will discuss, are you ready for Agile, what are the Agile methodologies, myths and facts of Agile, optimal techniques for introducing Agile and optimal development environments.