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.

Advertisements

“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…

Roles and Responsibilities BA vs PO vs SM

The Scrum Guide has this to say about the roles:

The Product Owner

The Product Owner is responsible for maximising the value of the product and the work of the Development Team. How this is done may vary widely across organisations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog.

The Scrum Master

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

The Business Analyst

Not actually mentioned…

mia

But…

The Business Analyst role is one that seems very common (and potentially very useful) addition to the team within Scrum. Their key role to facilitate understanding between the Product Owner/Business and the Development Team.

The Business Analyst should have the whole system view to reflect the single story view the developer/tester would have and so can answer the queries and fill in the details for the developer/tester.

We heard about a team where they were actively working to embed the BAs within the Scrum Team. As part of this journey the BAs were demoing stories at the Sprint Review!

In some instances the BA can proxy for the Product Owner, for example representing the PO in the Scrum ceremonies.

This does really depend on a significant level of trust from the Product Owner and it was not expected that the BA would sign anything off. Sign off of stories being the sole responsibility of the Product Owner as the single wringable neck.

We could also say that in effect the business analyst can be the person responsible for the mechanics – logging of stories, ensuring they are sprint ready etc – of the backlog while the product owner is responsible for the underlying content and priorities.

Problems

One common concern/problem is where the Product Owner and/or Business Analyst and/or Stakeholders are not fully engaged with the Scrum team. They tend to have a day job or are looking to the next project. In order for the Agile process to work we need someone who is empowered to make a decision – for example if a feature is Done, and we need some representative of the Business to at the very least engage with the ceremonies in Scrum in order that problems and progress can be be communicated in a timely fashion.

This lack of engagement can lead to delays in the delivery of the product – if a story isn’t signed off we would have to bring it forward into the next Sprint – this impacts average velocity and has further implications on any planning and delivery estimates. All to often this issue is never factored into why a project is apparently behind schedule and it’s the Scrum Team who are blamed.

Do we let the the project fail where we don’t have this engagement?

No Gods No Masters

One interesting case was of a team who had “lost” their Product Owner. This begged the question how did they determine what to work on?

The team received requests from the business and had an overarching road map of what projects were needed and there was a simple request of just do it. The team then determined the stories, the priority and when they expected to deliver. The Scrum Master controlled the Backlog adding the stories and tracking the work. Products were being delivered and the Team seemed happy with working this way.

The team had absorbed the Product Owner role and had enough subject matter knowledge to create viable stories.

Crazy? Well if it works…

 

 

How do you do long term planning when your organisation needs deadlines and lead times?

The first conversation for the 6th Practical Agile meeting considered Agile, Long Term Planning and Deadlines.

One common problem when planning seems to be that the deadline is often set from on high before a clear set of requirements are available.

There was a feeling that that is a spill over from the Waterfall world  where a set specification has a set end date (which, it was mentioned, was often missed).
Cart Before the Horse

The group felt that TShirt Sizing of a project (S, M, XL) was helpful in giving a finger in the air idea of how long it was felt a project would last but until the Project can be broken down into individual stories would a more realistic estimate of the time required be possible.

Once a backlog is in place prioritised and roughly estimated, if a team has an existing velocity, we are in a much better position to estimate (and by Estimate we mean Forecast rather than “Fixed Price Estimate“) what work is likely to be complete by any point in time. However a warning story came out that Estimates have been taken as Definite Dates to the point Marketing and Sales Teams started to use an Estimate as the basis for the selling the product!

There is a need to trust the teams to be honest as to what they feel the effort is (based on what they understand about a story at that time) and so using the velocity they can forecast what is likely to be completed by a given date. However this can only be a Snapshot. As the Backlog is continuously refined and potentially new features added to the project, the customer needs to be aware that what will be delivered will change. A Product Owner cannot expect to add a new feature into the backlog and expect no impact, and indeed it was suggested that the team need to emphasise almost one new story in by the project deadline, one story should be highlighted as dropping out for the project deadline. Which one of course would be up to the Product Owner. In any case the team, via the ScrumMaster, needs to make sure that these changes are reflected in the predicted delivery and that these revisions are communicated back to the Product Owner and stakeholders.

Story points are in key tool in any planning activity. An ideal is to have a full prioritised backlog of well constructed stories with acceptance criteria, which can then have the effort estimated using story points. We can use the established velocity of the team to forecast when stories are likely to be delivered and this can help drive the prioritisation of the backlog as the Product Owner can more easily see what value is likely to be delivered when. We can produce a burn up to illustrate a growth in effort and so highlight growth of a projects scope to the Product Owner in order to manage expectations and where necessary drive re-prioritisation and the understanding that if a new story will be worked on, other stories cannot be.

Burnup Example

Burn Up of a Project’s Scope

One issue that must be avoided (especially where the team has no established velocity) is to create a velocity that ensures that the estimated backlog will be completed by a specific deadline ie we have 5 sprints worth of time, the backlog is estimated at 200 points, therefore the team’s velocity gets set to 40. The team must, if necessary, be trusted to honestly come up with their own estimate of velocity based on what they feel is achievable in a sprint. Any forecast can (and should) be challenged, but the final call must be the people who will be doing the work.

One common factor everyone agreed to was that it is always best to have a Single Full time Product Owner who is ideally embedded with the team. It was also felt that far too often it was the Development Team who were blamed when a Project didn’t hit the deadline.

On the other hand it was felt developers (in particular) had a tendency to over estimate (although there were examples where they would under estimate). It must be recognised the estimation  is something people are bad at and though with time estimates will hopefully improve they are just a forecast and not a promise. This emphasises the need for continual refinement of the backlog and not just accepting any original estimate – with knowledge developed from experience in working on a particular project stories may require less effort (or more). Again the team needs to communicate clearly any impact of this refinement on what can be delivered.

For longer term planning Road Maps (an outline of what upcoming projects were due to be started) were considered to be very useful, not just in communicating the plan to the wider audiaence but also enabling the team(s) to start thinking about upcoming projects.

Release Planning was a very popular idea, even where it wasn’t being applied. It was felt that this would help communicate what features were to be delivered when for a project and could help with planning sales and training needs. Iterative Releases where only small changes were made was felt to be preferable to Big Bang Releases where much fuller training would be needed but there is often push back from the business who initially want to see everything released together. Feature switching was felt to be able to help find the best compromise between these two release strategies.

In summary – it felt from the discussion that Agile can provide useful forecasts as to what work is likely to have been completed by a deadline, but this must be subject to continuous review. The team can provide this forecast to enable the Product Owner (and so the business) to continuously evaluate what features will likely be available at any point and so judge the value of any further development.  What Agile cannot do is make is make the time and effort needed to complete a project arbitrarily match a deadline.

Reporting to management – what metrics do you use?

Due to the fact it was holiday season we had a small but enthusiastic group and the conversation took many interesting twists and turns.

Why Report?

The Product Owner needs to be seen to be delivering value for money. Agile is not a blank cheque and we need to justify what and why we are delivering. It is necessary to measure progress and enable early identification of issues.

Velocity

Velocity seemed to be a popular metric (Story Points per Sprint).  However it can be problematic in that initially it has to be an estimate and Project Managers can get rather twitchy. Once the Team has a few Sprints under their belt and an average velocity is available then it’s much more useful to both the team for Sprint Planning and for the Product Owner in giving a view of when the backlog could be potentially completed much longer  – however it’s still just an estimate and will be constantly refined.

Reclaim the Estimate

The group put forward that the word “Estimate” tends to be regarded in the same way as a “Fixed Price Estimate” ie the price you are expecting to pay.  It was suggested a better term might be “Forecast”.

How Much to Estimate?

As an interesting aside CA Technologies (formerly Rally) recently produced a survey that showed that in terms of performance “Lightweight Scrum” (Story Points only) was best , followed by “Full Scrum” (Story Points and Task Hours),  then “No Estimates” and finally “Hour-Oriented” (Task Hours only).
The survey is available here: http://www.projectmanagement.com/pdf/469163_the-impact-of-agile-quantified.pdf

(See also #NoEstimates)

An interesting example of estimating Tasks is rather than down to Hours is to estimate tasks in Half Days, as the it’s easier to think of finishing something this morning or by the end of the day – rather than I have x hours left to complete.

What to Report

In the Agile Manifesto we value  “Working software over comprehensive documentation” and this can be used to try and fob requests for documentation (and other metrics) off. We discussed that the Agile Manifesto also acknowledges “there is value in the items on the right”. So we need to ensure we have the Appropriate Level of Documentation and this needs to be determined up front so the Dev Team can account for it.

Any reporting needs to have value in that it is useful for the audience – if there is a need for Gannt Charts we needs to deliver them.

The group briefly touched on who should provide the metrics?  ScrumMaster seemed the obvious supplier but it was put forward that the ScrumMaster is a coaching and facilitating role and should it not be the Team delivering the metrics to the Product Owner who can then create the documentation for their audience. In reality it seemed that the ScrumMaster often provides any reports as needed.

And that was not all!

As well as the topic picked (and we never managed to get to the second as the group was in full flow) we also touched on

Discovery Phase – It is Valid as you only start Sprinting when you are ready.

Multi Skilled Teams – A title is your specialisation not your job.

Project Managers – Is a better term Delivery Managers?

Pair Programming – when training the learner should be doing the typing – muscle memory.

All in all it was a very enjoyable and intense session and I’m looking forward to the next one on September the 6th!

What’s the point of Scrum if you don’t “ship” regularly?

As everyone who’s looked even superficially into Scrum knows, there is a focus on creating a “potentially shippable increment of functionality”… but many projects or teams rarely actually ship incrementally or iteratively. In those cases, it’s sometimes hard to persuade teams of the importance of getting work “done” inside the timeboxed sprint because there may be another 10 sprints coming up before anything actually gets shipped.

For example, if you are approaching the last two or three days of a sprint and one of the developers informs the team at the standup that he’s finished all their work and that  they want to pull another story into the sprint.

However, there’s no chance that this story can be developed *and* tested within the remaining days in the sprint, you don’t have the resources to do this,  but they are a developer and they want to develop! They do not want to help out with testing, or help another developer finish their stories and they don’t see why it’s so important that things get tested in the same sprint as they are developed – after all this project isn’t going to ship until September, and all these stories still need to be developed.

Only when it comes towards the last couple of sprints of the project and the impending release to end users does the sharpness and focus really kick in, rather than having a constant focus and pace over the duration of the project.

This is a challenge, how do you as a scrum master persuade the team of the importance of driving work to a completed state within the timebox,  when from their perspective, it may not matter  – there’s always another sprint? It was observed that the rollover of work between sprints becomes habit forming if the boundaries of each sprint are regularly breached.

In this session, we started off discussing this  and unanimously agreed that releasing frequently to your customer is a very good thing and should be encouraged wherever possible, however as discussed in the very first session in April, that some businesses are just not able to handle regular releases through a range of factors.

A lot of the discussion centered around the importance of commitment – to the goals of the sprint and to the team and to the product owner and customer.It was felt that without such commitment, any team is potentially just  paying lip service to agility.

Two key messages came out of the discussions :

i)   Always ship in some way. Even if the organization can’t ship working software to the end user every sprint, look for another form of shipping… create a UAT environment and deploy the output of each sprint to that environment and have acceptance testing take place each sprint. The act of shipping even internally will reinforce the habit of producing “complete” functionality

ii)  Treat internal users and stakeholders with the same respect you would treat real customers. If the team takes internal stakeholders seriously then the focus on delivering to them will provide the required focus to get people to drive work to completion.

 

 

 

How do you Solve a Problem like Technical Debt?

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution

– techopedia

What is it?
The first issue addressed was what the group felt was meant by Technical Debt.

The first opinion was that it’s where the code was not fit for purpose – in that it sort of worked but was Spaghetti Code, hacked together to solve the problem but no underlying structure.  There was a strong sentiment that it’s not just programming and code but should also include a lack of adequate testing and  documentation.

Some of the traits of Technical Debt identified are:

  •  NOT Properly Developed
  •  NOT Architecturally Sound
  •  NOT Tested
  •  NOT Documented

Some of the sources of Technical Debt we identified came from quick Hacks to get things to work, Prototypes that become the Product, and Legacy Code.

A very valid point raised was whether we should necessarily use the term “technical debt” as it was felt the negative connotations of the “debt” implied fault and profligacy on the part of the team.

Some Solutions…
Stories to handle Tech Debt
Agile with its Iterative approach should be a good method to tackle Technical Debt as we should be able to add stories to the backlog to address it.
However can be problematic to sell these technical stories if there is no obvious benefit to the Business. For example if we spend a sprint tackling Technical Debt Stories – any demonstration will appear no different to the previous iteration (to the outside observer). If no obvious progress seen by PO/Business they will question the value of tackling Technical Debt “It works so what are you fixing?”

Prototype become the Product
A very interesting idea to prevent prototypes becoming the product was to keep it ragged enough that it’s obviously not finished article.

A Technical Debt Sprint
One proposal was to tackle Technical Debt as a Sprint at the end of the project. However there is potentially a lack of awareness that this does have a real Commercial Cost.

Or Not…
Just Incur the Debt
There was a 180 degree difference in what some participants felt about dealing with Technical Debt. One side saw Technical Debt as something that the team are happy to incur and let slide for the sake of expediency, and the other side that it’s something that the team are battling to get prioritized.

Selling it to the Business
It was felt that to a large extent that getting the opportunity to tackle Technical Debt is very much a Business Decision and it’s up to us to sell the need to address Technical Debt (see above for why it’s not obvious that we need to).
We need to be clear that putting off dealing with the Technical Debt will (not might) cause problems further down the road. In particular the discussion identified:
Support Teams costs money – the worse state the code base is in the greater the time to identify and correct issues
Any new Development inherits the Technical Debt as a default overhead, which will slow down and so increase the cost of development.
This is going to happen. But these cost can appear very hypothetical to a Product Owner.
What we need is a real cost; If we can say Technical Debt is adding an additional 30% (say) on top of our development costs then that is a figure we can give to the Product Owner that they can relate to.

How can we put a number on it?
Our Agile Metrics can prove very useful here. Two great examples were:
Decreasing Velocity.
Can we identify that the Technical Debt is (at least partially) responsible?

Declining Velocity
Why is the Velocity Decreasing? Technical Debt?

Comparative Size of Stories.
If we can see a trend that the average Story Estimates are increasing in size – is Technical Debt responsible?

In Conclusion
Technical Debt needs to be dealt with or the team will find itself deeper and deeper into a Fire Fighting leading to more Technical Debt spiral. The Scrum team has to give the business options, explain (and lobby) the impacts and put the decision firmly in the hands of the customer (or Product Owner).