Category Archives: KanBan

agile, KanBan, leancoffee

West London Lean Coffee – November

Leave a comment

West London Lean Coffee – November. Here’s a write up of the event.

Lean Coffee

We had a group of 9 people and some great discussions.

Things We Discussed

Experiences of Beyond Budgeting

We talked about experiences of Beyond Budgeting and how working incrementally can help finance teams support agile technology teams. We thought that this would work best in non listed companies, and the key point was enabling buy-in from finance teams to the approach. Wondering what Beyond Budgeting is – look at this post.

How Do You Demonstrate Savings Of Scrum Before You Start?

How can you convince a team to try scrum, or any other agile methodology? How can you demonstrate the savings that could be possible? We discussed how focusing on the outcome was important and how selling a change as a low risk experiment could help you get approval to try something new out. It’s well worth looking at the information that Government Digital Services make available for hints and tips – if it works in government then it must be do-able elsewhere, right? 🙂

The Differences Between Startup Lean and Large Company Lean

Some great discussions about the differences between small and large companies and their cultures. We agreed that behaviour was very important and how the requirement for more structure comes as companies grow. There was a great example of sizes and one scales; making a business unit max 80 people, a squad no more than 12 and teams of 6-8. Once one reaches these limits then it’s most likely time to start thinking about an alternate organisational setup in order to keep a company able to effectively employ agile methodologies

It’s worth checking out Management 3.0 for more details on ways in which you can help build great teams.

If You Were Joining a Team Without a Specific  Remit To Implement Agile Then How Would You Approach It?

We talked about how joining a new team is a challenge and how one might initiate change, despite being the new person on the team. The key point were to not focus on agile as such, look at the culture and pain points and lead by example. Use the opportunity of being new to ask simple questions and highlight what might appear obvious. And make sure that the team can see what the improvement could be by using some agile approaches.

It’s also worth establishing if you have a remit to change things and if so, then understand what the change appetite of the company is.

Things We Didn’t Talk About

  • Differences between software and physical product lean and development.
  • Agile reporting beyond burn down.
  • Sizing bugs and estimations. This post from Johanna Rothman could be useful.
  • Tactics for handling sprint disruption.
  • Multiple mobile teams using the same codebase.
  • Agile and lean for the old and corporate.

The next Lean Coffee is on December 15th, 8:30am in Carluccio’s Westfield, Shepherds Bush. Hope to see you there.

Experiences, KanBan, leancoffee

West London Lean Coffee – October

Leave a comment

Last week saw the latest edition of West London Lean Coffee, slightly delayed from October into early November. We had a group of 8 people and some great discussions.

img_20161103_084636618

Things We Discussed

Does Agile Need Updating

A detailed discussion about whether the agile principles are still valid and if they are not then does the manifesto need updating. Is the language right? Is it just a matter of applying general principles to the correct context?

It’s worth reading this article from Ben Linders on the same subject.

Transitioning Teams From Waterfall

How can you transition teams from waterfall methodologies? We talked about the complexities when fixed deadlines are involved and how negotiation with Product Owners is key. We then discussed about the importance of focusing on outcomes and not outputs from a team and avoiding falling into a trap of merely doing mini waterfalls. Identifying where the value is and tying everything to measurable business goals can help. I’ve found a lot of what Johanna Rothman has written to be very useful in the past so it’s worth checking her website out.

Impact mapping is also great at ensuring that the team are focused on outcomes from the start.

Alternate Benefits To Contracting For Developers and Testers

We spoke about the difficulties of retaining employees when the contracting market is so strong and what could be done to help. Focusing on team culture is key and ensuring that there are strong, personal bonds between team members. Treating people like adults and helping them adapt to change, while protecting a team from a lot of outside influence can also help. The focus on autonomy, mastery and purpose in a role can mean that the money aspect becomes far less important.

It’s worth checking out Management 3.0 for more details on ways in which you can help build great teams.

How Best To Organise and Delineate Different Workstreams Across Kanban Boards

We talked about whether it was best to have one large Kanban board that covered a number of different workstreams, or let teams have their own. It was agreed that team ownership of boards was the clear winner and something like a portfolio board could be used to bring the results together if needed. We then talked about how using a tool like JIRA could also help and could be used for reporting as much as tracking.

It’s worth checking out some of the presentations from LeanKit as a starter to learn more and this blog post about Portfolio Kanban.

Integrating UX/UI Into Agile Delivery

What’s the best way to integrate UX and UI design into agile? Do you just have the designers work a sprint ahead? But what happens if there are problems with the designs?

We spoke about how putting regular checkpoints or design reviews into the process can help and getting the ‘QA’ aspects of the design process as early as possible can de-risk having design ahead of development.

Things We Didn’t Talk About

  • How do you know what are genuine (non vanity) metrics for MVP? This article could help.
  • Any experience about sizing addressable markets?

The next Lean Coffee is on November 24th, 8:30am in Carluccio’s Westfield, Shepherds Bush. Hope to see you there.

 

KanBan, management, SharePoint, team

KanBan for Management

Leave a comment

Finally, a post on KanBan 🙂

I’ve been running teams who have been using KanBan for a few years. We find it is a really useful methodology to use, especially for our maintenance and dedicated testing/ release teams. Being a little lighter than Scrum, it enables us to quickly re-prioritise backlog items; ideal when you don’t know when the next Showstopper bug is going to come in.

Recently I’ve started to take things a little further with a pilot in my management team, which consists of test managers, defect managers and product owners who are driving various software projects to completion, mostly in the maintenance and productisation phases. The pilot involves using KanBan to run the team and prioritise the various actions and items that we need to drive forwards.

We wanted a lightweight approach to the toolset, so rather than go for a heavy tool, or something online (company policy – nothing on 3rd party servers), we picked SherePoint. Daniel Roots excellent guide on how to setup a KanBan board in SharePoint has been invaluable and what we have now certainly fits our need. OK, so you may not want to use this to run a detailed software project without some adaptation, but for prioritising and driving the management backlog then it works just fine, especially when tasks are sync’d with Outlook.

Changing our way-of-working was, as usual, initially difficult, but quickly the benefits of being able to see what everyone was working on and where it was in the cycle became apparent. Figuring out the work in progress limits for the team was a challenge, given the varied nature of the different roles, but we found that, more often than not, our tasks relied on each other, and therefore our ‘internal’ WIP limits did too. This meant that the team did have a natural velocity and this could be used to set WIP limits accordingly.

You may wonder whether this approach sounds a little heavy-handed? I’d argue that it does not, simply because you always keep an action list or backlog for a management team. Maybe you have tried to colour-code it or tabulate it, in order to make it more visible? You are halfway there. Why not go the full way and try KanBan for it instead?