A dinner chat with Mike Vizdos

I've been following Mike Vizdos @mvizdos on Twitter for quite some time now.  His popular web site mixes a healthy dose of cartoon humor with some very practical and handy advice on utilizing Scrum.  So when Mike tweeted about being in Sacramento for the week we reached out and asked if he would be interested in exchanging ideas over some food and a couple of brews.  Thankfully, Mike was gracious enough to accept our offer.

We ended up discussing some engaging topics and ideas, many of which left me thinking and reflecting on for many days to come.  But there were a few discussion points that left an especially long-lasting impression.

Feature planning in an agile SAP implementation

In one of our previous posts we talked about the core roles and basic team structure in an agile SAP implementation.  We are now ready to take a look at one of the first steps in planning the implementation and assessing the work that will need to be done by each team - defining the project features. 

A feature (aka epic or epic story) is the next level down from the overall project in that a single project contains one or more features. There is no black and white rule on what makes up a feature but here are some guiding principles that we try to utilize:

Agile Terminology for SAP Project Teams

We don't need to tell anyone who is used to working with SAP that getting the terminology right is often a daunting task.  Agile project management brings with it a number of new terms that are critical to understand in order to be able to comprehend any of the detailed discussions on how agile can help you implement SAP solutions in a better way. These terms are by no means universal, but at BestXperts we do try to use the terminology that is most common in the agile circles, regardless if we are talking about SAP implementation projects or building a web application.

Team Structure in Agile SAP Implementation Projects

One of the first things that each software implementation project has to worry about is the general structure of the project team.  We at BestXperts have tried a few different variations of project team composition over the years and can definitely attest to the fact that there is no canned project team setup that will work on every project.

Constriction to Force Ourselves to Create

As I was reading Mike Cohn's "Agile Estimating and Planning" for the last couple of days, I've taken some notes that I thought were worth sharing and discussing.  The later sections of the book really focus on the technical aspects of agile planning, such as using points for estimation, planning poker, release planning, etc, all of which I was already fairly familiar with.  For me, most of the interesting observations were in the first half of Mike's book where estimating and planning is discussed in broader terms and contrasted with counter-part approaches in waterfall project management.

Things you SHOULDN'T do in an agile SAP implementation

It's one thing to have the desire to implement SAP software in an agile way, envisioning the benefits of significantly lower cost and much happier end-users.  It is a whole other thing to actually make it happen, resisting the constant desire to fall back to the old waterfall ways of doing things.  And have no doubt, that desire will be there for quite some time, like a juicy carrot on a stick - if only we could map the entire project in a Gantt chart, if only we could put a deadline on every task no matter how far out that task is, if only we could achieve precise estimates on anything and everything and compare them to actual time spent, then and only then we can take control of the project, determine exact go-live date and keep our executive management properly informed.  Falling into this type of thinking in an agile project is very simple.  Having the understanding, discipline and commitment to the core principles of agile throughout the entire project is often very difficult.

Do Tools Matter?

In a meeting last week, we got into a debate about the value of tools in an organization. Specifically, we were discussing the merits of our chosen IT demand management software and Agile Project Management tool and whether or not they can be credited with the increase in productivity that our group has achieved over the past few months. During this debate, the following statement was blurted out:

Tools don't matter.

Running SAP projects - the path from waterfall to agile

We at BestXperts did not adopt agile project management overnight. In fact, it took us years to come up with an approach that was both repeatable and scalable. At first we dispensed with the idea of massive upfront blueprinting and instead began to have many mini-cycles of blueprinting, realization and testing throughout the project. In the process, we started structuring our project schedules around “sprints” and conducting daily standups to facilitate active communication within project teams.