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?

Don’t Lose Focus on Collaboration.

I was looking for inspiration for the blog when I stumbled across this post by Satish Thatte on the Agile Management Blog.

Balancing Individual Focused Work with Collaborative Team Work: Open-Office Bullpens are Harmful!

I have always been a believer in making sure that my work is a balance of team-time to catch up on what’s going on and focus-time for the more complex and intricate tasks of my day-to-day. Working remote from my home office, it’s pretty easy for me to make that happen. When I really need to focus, I can just avoid my instant messenger, screen any non-urgent calls and dive into the deep pool of total concentration.

My colleagues who work in our “agile friendly” open plan offices are not so lucky. Yes, agile promotes co-location, but how useful is it really to have non-focused chatter in the background while you work? Let’s be honest, not every conversation that happens in an office is actually productive or even related to the work going on. We all chat with our co-workers about our weekends, where we should go for lunch, and so on… Yes, we also discuss our work, but not all the time is the topic of conversation really worth the interruption of and breaking our concentration.

Therefore I question, are open plan offices really the best layout for productive work?

Happy New Year!

Another year gone by, another set of project milestones achieved, another pile of features, enhancements and bugs evaluated, developed and fixed. If I may say so myself, 2013 was a fantastic year for our project!

We made the switch from waterfall to agile scrum. We became more focused, more transparent, more efficient and effective. We learned new tools, techniques and threw ourselves into the change. We tried, we failed, we tried again, we panicked and cursed, we never gave up – and when we look back now, we succeeded.

We involved more users and subject matter experts than ever before. We designed the software with our users for our users. We delivered high value, high impact solutions and earned great feedback and appreciation in return. Our product has never been better, our process is working and we have an incredibly talented, committed and positive team!

It is now 2014. The (never ending) cycle of software development begins once more. From where I am standing, I can’t wait to jump in! I feel motivated, I feel excited and I feel like I have a brilliant team in my corner itching to make our product even better.

So today, the first post of the New Year, it is all about inspiration, motivation and saying THANK YOU!

You all know who you are, you make our team awesome, you support each other, you work like crazy to deliver and you have fun doing it. Thank you for your hard work, your dedication and your energy.

Here’s to another great year!!

(Dis-)Organized.

This week I had a somewhat lastminute trip to the headoffice, so I didn’t remember to write a post in advance, so instead, I’ll feature another article today:

Reorganizing for Agility I by Anurag Prakash

Next time, I’ll try to be more organized.

The Gift of Feedback?

After an interesting conversation among my fellow Product Owners yesterday, I thought today’s post should be about something we always ask for, often receive and are not always happy about: feedback. In the English language of the corporate world, this is often referred to as the “gift of feedback”. For me, this expression always holds a certain sense of irony. While in English “gift” pretty simply means something that is given, in my native language German, “Gift” actually translates as poison.

Of course feedback is always a good thing, after all, what good is anything if I am the only one who thinks so, but there are certainly occasions where feedback can “poison a plan” – a sprint plan for example. Every now and then one of our showcases throws light on some additional feature, nuance and business scenario previously unaccounted for which the scrum team then dutifully investigates, vets and puts on the sprint plan for the next iteration. Perfect agile process, right?

The problem is though, since the showcase is at the end of a sprint, invariably most of the sprint planning for the following sprint has already been done by the team’s PO. Having to incorporate another item that late in the game does not a happy developer make! Agile scrum in itself is already a very challenging process at the best of times and including showcase feedback aka added scope at the last minute before the start of a sprint only increases the pressure.

So, what to do? Unless the basic principle of improving a product by iteration is completely thrown overboard, we must continually ask for feedback, digest it and include in our product moving forward. Otherwise, we are no longer agile, we are just “waterfalling” within a somewhat agile structure. The question remains though, what is the best way to accommodate feedback without disrupting the work for the following sprint? Schedule it to be done later, the following sprint perhaps? Plus, by simply accepting whatever feedback is given to us in a showcase and immediately implementing it in the next sprint, are we missing the opportunity to dive deeper into what we are missing and taking the time to truly understand the customer ask?

What about you – in your scrum process, how do you avoid the “Gift” in feedback?

Scope Creep.

In any kind of project “scope creep” is a term that comes up often. Depending on the kind of project, it may happen rarely or frequently, but in my experience it’s safe to say that there is always a certain level of scope creep, or at the very least, the continuous threat that it may surface.

While scope creep is mostly related to additional development work, further testing required or perhaps another chunk of analysis previously unaccounted for, what I have observed recently is a more subtle kind of scope creep. In fact, it is not even related to the technology or software of our project. Instead, we seem to be suffering some blurring of the boundaries when it comes to our agile scrum process, more specifically the purpose and content of the scrum gatherings.

When we first started working in the scrum module, a great emphasis was placed on making sure we setup the correct cadence of meetings. As per the scrum model, we dutifully setup daily standups, regular retrospectives and sprint planning sessions and of course end of sprint showcases to demonstrate the development completed to our stakeholders for feedback.

The one meeting where I have noticed a big change over the course of the past weeks and months is the showcase. It seems that we slowly but surely move away from the true essence of showing a live demo for the respective scrum teams, so our stakeholders and other teams can see the progress, the decisions made and provide feedback on the same. Instead, it seems the meetings is morphing into more of a general project update session.

Not that getting an update on what other teams are up to is not valuable time for everyone involved, it most certainly is, however I wonder whether the scrum showcase is really the right forum or whether we should try to go back to purely focusing on the demo of new software and put a stop to this new kind of “scope creep”…

Innovate!

I was going to write a proper post today, now that I am back in the office, but then I found the below article and I felt compelled to share it. In my opinion, it is such an accessible and apt description of what it takes to innovate that I think can enlighten and inspire anyone to try doing things in an agile way.

5 Steps to build a more innovative organization by The Staffing Advisor

Thinking about agile? Don’t hesitate, innovate!

Crossword.

Since most of my friends are actually not involved in the world of software development, when trying to describe what I do and how we do it, I tend to try and make comparisons to real life scenarios they can relate to. Today, I thought I’d share a wonderful example I stumbled across a little while ago;

 The Crossword Effect by Clarke Ching (Clarke Ching’s Rocks And Snowballs)

Wish I had come up with that one myself….

 

A Man’s thoughts on Commitment.

Since I have been monopolizing ladies in agile last week, let’s start this week with a male voice – funnily enough talking about commitment, which if you ever watched a romantic comedy, is supposedly the last thing on their minds. 😉

Just one thing… by Eric Willeke

Hope you like it!