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

Collaboration.

Working in a large global corporation, it always baffles me how little we actually collaborate and utilize each other’s talents. I don’t mean working within my small team or even my extended product owner team, but across disciplines, teams and departments. Why do we hesitate so much to seek the assistance of others? Do we shy away from admitting that we could use some help? Are we afraid to lose control if we let others in on “our” area of expertise?

You might wonder what this post has to do with agile and well, perhaps it doesn’t specifically. It only crossed my mind since agile puts such a large emphasis on team work, collaboration, co-location, crossing skill sets… seems that these are all things we should embrace, not just on our agile lanes and scrum teams, but in our organization as a whole.

I try to encourage exchange of ideas by reaching out for help, offering to assist someone and most of all, genuinely invite somebody to challenge my point of view. I seem to get the best ideas when somebody challenges my initial approach and calls out my assumptions. I mean, as much as I would like to, I can’t be right all the time…and I am sure we can all benefit from a little more constructive feedback.

As it stands today, I think we have quite a way to go to communicate and collaborate successfully… There is a lot of talent out there and we can only to reach our full potential if we continue to challenge ourselves and others.

The post Collaboration first appeared on Agile, Now What?

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?

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!!

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!

Iterative Increments.

I’ll be back later this week, so for now, this is the last of the series of guest stars on the blog, today let’s go back to basics:

We iterate …so we are Agile? by Illya Pavlichenko (via scrumalliance.com)

See you on Thursday!