Perfect Software – The Enemy of Rapid Delivery?

We all want things to be perfect, right?  But are we making software delivery much harder for ourselves in the strive for perfection?

perfect

But, who is it that defines perfect?  Is it the Architect?  The Product Owner?  Maybe… Who knows! – it seems to differ from one organisation to the next.  Whose version of perfection are you trying to meet?

Imagine a scenario where you are unable to release version one of your software because your architect is demanding answers about version 2 and 3 – which you know that you’re never likely to get to anyway.  You’d be feeling pretty frustrated.  On the flip side, being prompted about the plans for V2 could mean you totally rethink the way you’ve done V1, saving time and effort later.

magic8ballDontCountOnIt

 

Then someone says “Make it future proof”.

What does this even mean?

And is that future ever going to come?

 

 

In a perfect world, to be able to release perfect software we would need to make small changes regularly rather than large releases.  We would also need to have full control over:

  • The requirements
  • The development and test environments
  • The target environment
  • The release mechanism
  • Probably the users too…!

So rather than perfect, should we be striving for Good Enough?  It will depend on the team culture and how risk averse the company are.  This can be influenced by how quickly problems can be fixed, the size of the user base and how exposed any issues would be.  During Spotify’s video describing their engineering model (here) they talk about one of their motto’s – “Never Wrong Long”.  They can release more frequently because wherever possible they deal in small changes rather than large projects.  They also have the advantage that their architecture is decoupled enough that any problems would have a smaller area of impact and any problems can be resolved quickly.

So, is perfect software the enemy of rapid delivery?  It depends on many factors.  It seems to me that the ideal would be to have small, frequent, iterative deliveries that are quick and painless to release – then if it doesn’t meet someone’s idea of perfect, it can be quickly revisited.

 

Communication in Agile Teams

The second of the April Practical Agile’s Meetup discussions concerned communication in Agile teams.
Tin Can Phone

The first subject that came up was how do you signal your availability to communicate? A “Headphone” standard was proposed as follows:

  • Both Headphones in – I’m in the zone. Leave me alone. Send me an eMessage.
  • One Headphone in – I’m busy but available to communicate.
  • No Headphones in – I’m eager to communicate.

This did lead to the question of how much headphone usage was acceptable? We’d hope that in a self organising team that individual would be putting the needs of the team first and would be actively listening and ready to contribute as necessary – not just to their immediate team, but to the whole .  If the job is getting done is there a problem? It goes back to the concept of T-Shaped People.

How much communication needs to be recorded was a clear topic. The Agile Manifesto values “Working software over comprehensive documentation” but we need to remember that the documentation side still has value. An interesting perspective was that the User Story was a promise to have a conversation. Decisions should be logged somehow – and the use of tools such as TFS and Jira can be easily used to record PO decisions etc. The standard rule of thumb seems to be if you need to ask the question record the answer.

An interesting perspective was that the User Story was a promise to have a conversation – which aligns with the Agile Manifesto valuing “Customer collaboration over contract negotiation”.

Over communication can be a problem with “Reply To All” being regarded as the work of the devil – though perhaps the original emailer may be to blame for distributing it too widely in the first place?

Definition of Ready can be useful by clarifying what criteria is needed to start and leading to discussion of If and Why a story is not ready. BDD and Given-When-Then style criteria (Gherkin) can help clarify any issues and pick out any assumptions,

A team needs to be realistic and be comfortable that some of the finer detail can be thrashed out once the story has been started. The team should be empowered enough can consider whether they feeling any “missing” details are within the remit of the team to determine.

Amigo sessions were once again highlighted as useful tool – helping to kick off communication and common understanding.

It was raised that a mature team’s definition of ready can be unspoken, but on the other hand this could cause confusion for any new joiners.

Who would cross the Bridge of Death must answer me these standard questions three, ere the other side he see

Monty Python and the Holy Grail - The Bridgekeeper

What is your name? What is your quest? What is the average velocity of a 2 week sprint?

The daily Stand-ups were discussed. The value of the 3 standard questions was questioned. An opinion that a simple update as to what you were working on should suffice as the team should already be aware of any issues and problems was generally agreed with.

The Stand-up can also be used as a check before any new work is started that there are no in-play tasks that could be assisted with. The team need to be focusing on the bigger picture rather than just their “own” tasks and a Story isn’t done till it’s all done.

A useful Stand-up tool that has been mentioned before was a confidence check.  After the updates  each participant gives their confidence in completing the Sprint goals by revealing a number of fingers – Five for Very Confident to One for Very Worried. This can stimulate conversation and potentially address problems early by focusing the team on them.

Finally, I think what really ran through the discussion is that Communication is about Respect. I’m off to put on my headphones and look forward to seeing you next time.

What is the perfect office environment for agile development?

The first of the April Practical Agile Meetup’s  conversations was about the best environment for agile development.

Disney Castle

When you develop upon a star…

And the first thoughts were “It Depends”.  Different stages of the development have different needs. Discovery needs a space for discussion, Development needs somewhere to sit.  A fixed space is bad and teams ideally should be able to determine their own layout (taking into consideration Health and Safety requirements).

The Disney Brainstorming Method was brought up. This is a process for creating and refining new ideas using Dreamer, Realist and Spoiler point of view.  The idea is using 3 separate rooms where only the Dreamer POV is allowed in the first, only Realist POV is the second and only Spoiler POV in the third. The idea behind this is many ideas can be examined and refined without stifling initial creativity.

Whiteboards proved a great source for discussion, with many teams using them to partition off their workspaces in open plan offices in addition to their more traditional role as scrum boards and idea capture.

It was felt that all too often that everything gets written down and they can quickly become noisy and out of date. We’ve all encountered the lonely whiteboard in a deserted room with “please do not clean” scrawled on it. If it’s important why not take a photo and then it can be filed and shared as needed and the board is ready to be used again?

The group discussed the virtues of Physical vs Virtual  Scrum boards. Many teams used both which led to the question of which one showed the reality? The majority opinion was it would be the electronic version but that it needs to be used properly with team members burning down estimates and making sure tasks and stories were updated in a timely manner.

The duplication of information has a potential of causing confusion and in some cases the Scrum Master updated the physical board to make sure it reflects the virtual board.

Many teams have large monitors to display the team metric. One point of view was that this can be seen as a pure PR exercise to show internal and external customers that this is a high tech hub activity. However real time data can be very useful to the team where it is appropriate and desired – for example build health.

The need for a public display of information was felt to be an important part of the Transparency needed for Agile by making easily visible the progress and status of work to the team, stakeholders and other teams. Again this brings up the need to identify what is needed and useful to communicate to the wider audience as well as the team.

One common issue always seems to be noise level; My team has a healthy buzz, Your team is making a racket. Communication is central to agile. Tolerance and Respect for each other would seem to be the solution, with team members feeling comfortable enough to call out when there are issues.

As an offshoot from the main topic under discussion, an interesting method of dealing with tardy team members ( a general sore point for everyone) was suggested. At every meeting an individual is late for a mark is tallied against their name.  At the end of the week/sprint the team member with the most tardy marks buys the treats.

Clock Cake

There’s always time for cake!

Developer-centric Teams

The second conversation of our March Practical Agile session was kicked off from the question –

“How do you prevent teams and discussions being dominated by developers?”

The God-King Xerxes

All the God-King Xerxes requires is this: a simple offering of Code and Test

The first reactions were that it wasn’t necessarily the developers who dominated, but that it was not an uncommon scenario.

The underlying issue seemed to relate to the culture of the team and wider business especially where a more traditional waterfall mindset was the norm.

Other problems seemed to relate to the state of stories and it was felt that making sure we have a good and well understood definition of “Ready” (to start work) was available as if we know and are satisfied that the story was ready we also have a firm grasp when it would be done. This can cause problems though if the team try and use this as an excuse not to commit to a story and an appreciation that  “Ready” means “Good enough to Start” with an understanding that some of the finer detail can only be drawn out once work is underway.  On the other hand this cannot be allowed to lead to Feature Creep of the Story with the temptation to add “just one more thing”.

The Three Amigos approach where a Coder, a Tester and a Business Analyst go over each story in an informal kick-off session to give a common shared vision of what will be delivered and helps ensure that it is the voice of the team rather than just a single opinion. As well as helping to prevent domination by one area, the 3 Amigos helps communication between the disciplines and promotes understanding of the work required from each area; Development may be relatively straight forward but the test effort is significant (or vice versa). This closer working helps that understanding of what  all sides need to get the story into “Done”.

One area which could drive the perception of developer pushiness is in the technical detail and especially technical debt. It is felt that Product Owners may not appreciate the reasons and value of the technical side and the team needs to be clear about why this needs to be tackled early and the benefits both short (the system will perform better) and longer (future development will be more difficult and take longer) need to be be made clear. For example a conversation along the lines of if we take x hours to correct the code now we will save y hours developing future stories helps clarify that value of doing things correctly in the first place. On the other hand, developers do need to be realistic and there may well be reasons that a feature is needed now – ideally both business and development team need to understand why and what that is driving their needs.

In all cases the Scrum Master has a key role in managing any negative perceptions of dominance. They need to facilitate the ceremonies and meetings to enable all voices to be heard and valued.  They should make space to allow technical requirements and debt to become valued stories and not just an afterthought. The Scrum Master needs to protect the team by identifying and stopping Story Scope creep, encouraging the Product Owner to spin off a new story to address any new/missing requirement not identified when the Story was committed to the Sprint where reasonable, but also making sure that a Story is not approved where the minor details still need to be refined.

Finally what is needed is Respect from all sides, Communication leading to joint understanding of the project , and clear Value for what we are creating.

T-Shaped People

The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own. – Wikipedia

The first topic up for discussion at our March Meetup was about “T-Shaped People”.

Mr. T

I Pi-“T”-y the Fool

A T-shaped person was considered to have a specialisation (Coding, Testing, Analysis) as the Vertical to the T but with at least an understanding of other complimentary areas as the Horizontal to the T. The idea that a person could be skilled in all things was felt to be an unhelpful ideal and rarely existed in reality.

The discussion then brought up areas where it seemed a T shaped forms almost naturally. Examples included Testers having great analytic skills, Analysts having customer focus and so potentially able to see testing and UX skills. This led to the feeling that T shaped people need a Team, where they can be critical of themselves  and allow themselves to be criticised, in order to be most effective.

T-shaped people will develop when the team is actively pulling together to meet the teams goals. The team must appreciate that the team succeeds (as in the story is done) rather than the individual succeeds (the coding in complete, a bug has been found).

A useful tool repeatedly referenced as a way of helping increase the awareness between different specialisations was “Three Amigos

With the Three Amigos a Coder, a Tester and an Analyst come together to discuss a story’s criteria and remove any misunderstandings about what the story should deliver. They can then discuss the development and testing approach to increase understanding and potentially reduce any duplication of effort. This early working together can help increase appreciation of the others jobs and add to the Horizontal Bar of the T as each of the Amigos learns from their counterparts.

The Three Amigoes

I’m Business!  I’m Development!  And I’m Testing!  And together we are The Primary Perspectives!

The subject of closer working was considered. Pair programming has many benefits – including better code quality. Pairing a Tester and Developer seemed very desirable especially where Test Driven Development was the idea. The pairing works together not to “find” bugs, but to identify and address issues as quickly as possible in order to be able to drive a story to “Done”. There was some concern as to making sure that a critical distance was maintained to ensure that neither side was dominating the scope of the testing or development.  Again the 3 Amigos technique helps to drive this behaviour by forging that common understanding up front.

One further question raised was how deep should a tester go? Should they be reviewing the code? It was felt that that it is helpful for a tester should know the basics which would be sufficient to “talk” to the developer without needing the fine detail.

In conclusion there seemed broad agreement that a T Shaped Person is defined by their Mindset (What can I do?) rather than their Skillset (I can do this) and the desire to ensure that the Team succeeds and not just the individual.

Outside Perceptions of Agile Teams?

The first conversation for February’s Meetup (yes we’re now organising the sessions via Meetup) kicked off from the question of how are Agile teams seen from “Outside”.

ghostoffrank2

One thing I noticed (and it may just have been me) from the conversation was that the Agile team seemed only noticed when something was perceived to be going wrong – burndown not moving down or delivery dates slipping for example.

The subject of Overtime was one of the first subjects brought up. There is sometimes an expectation that teams should be working overtime.  If the team is meeting its commitments it’s a question that should not be asked and there was a feeling that overtime should be a last resort – though there was an appreciation that business needs have to be paramount and there may be occasions that overtime is necessary.

Adding additional resources was also touched on. Again there seems to be a perception that all developers and testers were an equal resource and that just throwing more bodies at it would solve the problem. No consideration seems to be considered about the time upskill any new team members and the negative impact that “too many cooks” can have.

The group considered why overtime/additional resourcing might be expected. Too much work left in the backlog was one reason  – 24 weeks of work left when 12 weeks till the project was due to end. This led to consideration of how such a scenario could happen.

Scope creep seemed to be a major concern – one example given was a rise in 300% from the initial backlog – and it is felt the onus has to be on the Product Owner to make the decision as to the value and necessity (such as legal requirements) of any additions in the prioritisation of the backlog. The Team does have a responsibility in communicating to the Product Owner (and so to the wider audience) what is achievable as the backlog expands via velocity and the backlog.

There was some concern that scope creep can arise as that a particular business area is worried that the team would only ever deliver the minimum viable product before moving to the next project and that they would never get the full functionality

Demands for overtime and/or throwing resources need to be countered with evidence. There are plenty of case studies that demonstrate the negative effects of continually working additional hours.  There’s a great PDF Rules of Productivity from Daniel Cook which provides a starting point for this sort of discussion.

Another negative perception could be where observers start comparing teams based, for example, on velocities. A team with a “lower” velocity could be misidentified as not working hard enough. This seems to stem from a misunderstanding about how each individual team estimates its own work and that velocities should not be used in this way. Teams often seem to be assumed to be the same with no consideration made of individual differences or skills. If there is an issue within a specific team then that is for the scrum master and line manager to address.

Conflict also arises where the team are working in an agile style but the expectations and culture of the business are around a more traditional project management process.  An organisation used to “Big Bang” releases may be uncomfortable with the Agile process and the perceived additional demands on time from the ceremonies. The lack of certainty over requirements mean Agile processes tend not to work well where Project Managers and the business are expecting to see a hardened Gantt chart.

This lack of certainty especially at the start of the project can be unnerving with an agile team only looking to refine the stories required for the next couple of time. The “Just In Time” estimates can make planning difficult especially as the team break down larger stories into more manageable ones as their understanding grows. A discovery sprint is always worthwhile with the team “T-shirt” sizing the full backlog to give an idea of the complexity and effort required of the project. An understanding needs to be made that this is only a finger in the air estimate and that this will change (no-one had an example of it decreasing) as the project scope is better understood over time.

Agile needs to be sold to the wider business as something to aspire to and the agile team do need to recognise that the business may not quite be there yet.

As an aside it was brought up that sometimes it felt that those complaining most could often be the greatest source of impediments! In this case the scrum master needs to push back on these impediments.

So what can we do?

Some solutions raised were:

Educate – if the development team is working using agile methodology they are well positioned to inform the wider business about agile working.  We did a brown bag lunch on Agile – Agile in An Hour – presenting some of the core agile concepts to a wider audience. It also may worth suggesting (as has come up in previous Practical Agile sessions) more formal training for the decision makers within the business. In addition make sure the people who need to know what’s going on are included in reviews.

Pushback – in many cases problems always seems to fall-back on the development team. It must be remembered that it is the Product Owner who is accountable for the value delivered. They need to be aware of the impact of any new stories and make sure they are prioritised appropriately and that they need to be realistic about what can be delivered.

The team should also make sure any external impediments or blockers are raised and followed up to clear them as quickly as possible. The Product Owner needs to be in this loop in order to help the team and also that they are aware of external factors impacting the project as quickly as possible.

Be Realistic – Agile in itself is not the goal. The Business rarely cares how the product is delivered, just that it is! The team should work with the wider business on Release Plans and strive where possible to reduce the uncertainty as quickly as possible.

“Permanent Teams” vs Mixing It Up

This discussion was triggered from considering the benefits and issues of keeping a permanent scrum team(s) versus mixing the team(s) up.

iwantadog-06

It was felt that it was important to consider what team members would like – they may want to move and gain experience of more areas of the business, or they may be bored with their current project and wish to work on something fresher. Equally they may want to stay with their established team and it’s important to communicate why any potential move is needed or why it’s not possible at the current time.

The impact of moving people around and reforming established teams (leading to a fresh bout of Storming, Norming, Performing) can form disruption to a team that is working well as the new body will need to be brought up to speed on the project, and the team may take a while to get back into the honesty and trust for effective retrospectives, both of which will have an impact on the team’s velocity. Care must be taken to ensure the apple cart isn’t upset.

One example of mixing teams was where several different contractors were used.  In this case the client wanted mixed teams (each with a mix of contractors) to help prevent competition between the teams (which the client felt was unhelpful) and potential prevent the danger of a particular contractor “carrying” people (though no-one was sure that would actually happen).

When constructing a team we need to try and match the right personalities. It was put forward that team composition could be influenced by scientific methods such Belbin in order to build the teams and help avoid conflicting personalities.

One Idea would be a Pool of Resources which are assigned to teams in order to maximise their value – a UX expert may not have as much value to a back end project and so may be better utilised on another project. However this could impact the project as the teams have to stabilise (if we are regularly reorganising teams) and if the resource is “parachuted” in to an existing team the feeling from both new resource and the team that they are not really part of the team – “You weren’t there Man”.

One problem with long term projects and static teams raised was where single points of failure arose ie team members with all the ‘knowledge’ of the project. There was then some discussion of how XP techniques could help alleviate this by helping to share knowledge.  One potential problem with using XP techniques such as Mob and/or Pair programming is that outside observers may not appreciate the benefits and only see two (or more in the case of mob programming) expensive resources using one computer.

If a stable team is proving to be successful – delivering its commitments and working well it would seem desirable to keep it stable and it would be wise to consider the impact of any disruption team member changes could cause on the ongoing success of the team.

So the general opinion as to which was better – Permanent Teams or Mixing them up?

It Depends…