The Agile Mindset

I have been rather slack at writing for the blog in the past few weeks – seems that my day job as taken all my time and focus, so not much left for my poor neglected blog. So it doesn’t stay so so empty, here are some thought provoking words from a fellow agilist.
Enjoy!

The Agile Warrior

Agile has been around for over a decade, a lot of people are doing it, and that’s great.

But I see a lot of organizations struggling. Not so much with the tools and practices. But mostly in the mind – the head.

Here are a list of thoughts and attitudes companies need to get if they are going to truly adopt Agile as a means of delivery.

The plan is going to change

Plan the work, work the plan. That’s the mantra traditional project management has been teaching PMs for years. Except that it doesn’t work. Companies that expect software projects to be straight lines. But they look a lot more like this:

and it’s this unwillingness to change the plan that kills them – Agile or not.

Everyones has a plan until they get punched in the face. – Mike Tyson

Software projects are a bit like getting in…

View original post 1,240 more words

Board Meeting.

I wanted to share another article and blog with you today, one that I go to for inspiration and ideas both for my day to day work life and for new topics for my blog.

5-Minute Board Test by Pawel Brodzinski  of Pawel Brodzinski on Software Project Management

This particular piece is about Kanban and more specifically about designing a well functioning visual board to track your team’s progress. Like I mentioned previously, I am a big fan of visual management and display of information, but as Pawel rightly points out, team boards, whether for Kanban or Scrum, are only really effective if they are simple enough to be (almost) self-explanatory.

How good is your board?

 

The post Board Meeting first appeared on Agile, Now What?

Scrumban.

At the moment, I am helping out on a slightly different team on my project as an “adhoc PO”. While the rest of our project is pretty much scrum all the way, this team works a bit differently. They are not strictly setup as a scrum team with one scrum master and one product owner, as well as development and QA teams. In this case, because of the size of the backlog, we have a pretty large development team that makes it difficult if not impossible to support with just the one product owner.

The main focus for this team is our backlog of “next-in-line-but-not-necessarily-vital” items AKA product maintenance. All of the pieces on this particular backlog are important, relevant and need to get done, but they don’t or didn’t quite fit in any of our scrum lane work over the past few releases. The tricky thing is that all of these items are not as obviously related or structured as the rest of our backlog, hence making it much harder to properly prioritize and stack rank for the PO on the team.

Also, since this team is also responsible for supporting and fixing any new enhancements or bugs that user report or request, the backlog is nowhere near as complete or static as the rest of our scrum lane backlogs. Planning a backlog on shifting sand as it where, meant that our project leadership decided that perhaps scrum wasn’t quite the right model for this team, although they were very keen on continuing down the agile road.

Enter Kanban – a model out of the lean toolbox that is often adopted on the factory shop floor and at it’s most basic form features a just-in-time and off-the-top-of-the-pile approach to development. In essence, the backlog is prioritized and stack ranked and as soon as any developer has an opening, either because they finished their current story or because they have some idle time while working on another story, they pick up the next item from the top of the backlog queue.

Because of this model, stack ranking in Kanban is possibly even more important than in scrum, to ensure that the flow of work doesn’t stop and the production line never breaks. And this is exactly why we decided to not only assign more than one product owner to this team, but also went for the slightly unusual approach of having “adhoc POs” – such as myself – to lend a hand and help groom the backlog to make sure we can maximize the team’s capacity and effectiveness.

I really am looking forward to getting a little more immersed and learn more about Kanban vs Scrum – so far, it’s an interesting new perspective.

 

The post Scrumban first appeared on Agile, Now What?

Yes, we Kanban.

Staying in the South for the rest of this week, here’s an inspiring story of an agile transformation implementing Kanban, starting with just 15 minutes a day – sort of wish we had done it this way:

Using Kanban to simplify and save time on complex enterprise projects by Stephanie (bysouth)

Thanks!