shelidonJuly 11, 20191 Comment on Agile GIS

San Diego, 10.07.2019. Esri UC

As you know, I’m a big supporter of using Agile, Kanban and Scrum in a project. I’ve seen some talk around Agile and BIM, at Autodesk University London last year, and it was nice to see Esri giving a corporate talk about their own best practices in applying Agile in both development and consultancy. I couldn’t miss this. The name of the talk was:

Esri Best Practices: AGILE Project Management
Lana Thlka
Jessica Schrage

The class started by giving a quick overview of a few basic concepts, starting from a basic question:

Why using Agile at all?

In going back to the Agile manifesto and to why the method was invented in the first place, the answer seems to be the same nowadays and in our field as well: people get frustrated from constant changes, from their work not being used and becoming superseded before it’s even deployed, from requirements evolving and changing over time.
Agile means your work gets deployed quicker, and apparently this is important for everybody.

They then showed three main frameworks that are alternative to what we consider traditional project management: Waterfall. Among these three, two of them should sound familiar to the readers of my blog and those who attended what we call Boost. They are:

• Kanban, here mainly intended as the kanban board, and the shown version was divided into steps being:
  • Pending;
  • Analysis;
  • Development;
  • Test;
  • Deploy.
• Scrum, here applied with two weeks sprints and retrospectives at the end of each sprint;
• SAFe Scalable Agile Framework, which was basically described as Scrum on steroids (a definition that I find adorable) and involves figures such as a Release manager and a Scrum of Scrum Masters, basically a Scrum Master to Rule Them All.

So, the question that arises is…

When models work best?

A beautiful diagnostic was proposed and I give it to you as it is, just polished for readability as my pictures always suck.

Having cleared this up, the second question was bound to be about…

Estimating the Work

If you use Agile when you don’t have clear requirements, how the hell do you develop a proposal?
The system shown was a quite traditional one in Scrum, involving the usage of Epics to identify features. They then assign what we call Story points, which are an arbitrary measure used by Scrum. You might remember me talking about them when I showed you some Scrum Poker. The Story Points scale they use is something along the line of a Fibonacci Sequence.

1 2 3 5 8 13 21 34 54

Hence, the rabbit in the header. Congratulations: you waited so far.

You then multiply the points by a factor that depends on the level of optimism of your team et voilà, you have your hours.

Managing the Work

Few tools were presented:

• Microsoft team foundation server (TFS);
• Rally agile implementation tool;
• Trello (of course) with pipelines implemented;
• GitHub (good for developers) with the Waffle plug-in.

A good comparison scheme was presented between the tools, and you’re going to have to see it in one of my horrible pictures.

Reports

A thing that was taken into great consideration was the need to export reports from the tools, so keep in mind that some agile tools like Trello have a huge management overhead as you need to report lots of activities manually. There is a Report Generator in the Power-Ups, but it wasn’t mentioned and, personally, I never tried it.

Another good hint was given in regards as to mixing methods: in a consulting project, you will probably find yourself doing waterfall at the beginning (sprint zero, when you’re setting up stuff), agile in the middle and waterfall in the end (when you need to wrap up what the client is expecting.

A neat tool shown was the one on Rallydev.com (with kanban stages set up as: defined, in progress, completed, accepted). I honestly can’t wait to try it.

Stand up meetings

Stand up meetings are an integral part of Scrum and in order for them to work, they need to brief and effective. These were the hints that Lana and Jessica gave:

• it needs to last 15 minutes tops and needs to ask 3 basic questions:
  • What did you complete yesterday?
  • What have you planned for today?
  • Are you facing any obstacle?

Managing resources

Another tricky thing when it comes to Scrum, starting with a pun:

• scenario A: people are working only on your project… the room reacts with a nervous laugh;
• enters scenario B: people are busy, so ask them to commit a percentage of their time for the sprint.

If scenario B fails, you have to go to Plan Z and add new people to the team, meaning you have to train them and give them time to adapt, thus slowing everybody down in order to go faster. This is never good. Aim for Scenario B.

Case Studies

The lesson ended with three anonymous case studies for three different scales of projects and the three different methods:

• Small Scale: Agile was used to ease post-production and follow-on support after the release;
  • an interesting key point for me was the note about the lapse between sprints: how many times your team doesn’t work consistently on a project and how has that affect the project that keeps coming and going?
• Medium Scale: Agile was used because the client was fairly new to the technology and thus didn’t know what to ask for;
• Large Scale: SAFe Agile was used because of contract requirements, but requirements were also vague (meaning that probably the client didn’t know what he was doing from a technical point of view but someone around there knew that they didn’t know).

I hope you found this interesting, ’cause I certainly did.
I have a couple more things to share with you, that fell behind from yesterday, and today I have a whole full day of conference ahead of me.
Bring it on!