#Agile versus #Agenda – #Rugby versus #Football #PMOT #JIRA #Sciforma #Favre

We were talking the other day about software products that are used to help the execution of projects in either an Agile or Traditional manner. In particular, the discussion was the difference in models used in JIRA versus Sciforma. JIRA follows the Agile or KanBan model while Sciforma follows the Traditional or Scheduled model. The difference between the two models seemed to be grounded in the concepts of whether planning is done in the temporal dimension. (i.e. have we created a preliminary schedule of when activities or tasks would be done and considered dependencies) In fact, you can’t plan in JIRA temporalily without buying add-on components like Tempo-Planner. (Which is probably where they ended up getting the name from)

Rugby versus Football

First of all, when I mention Football I am referring to the American or Canadian version of football. Sorry european and world Soccer fans.

It then became apparent how good of an analogy Rugby versus Football is for Agile versus Traditional.

There were three important observations:

      1. Agile isn’t better than Traditional and Traditional isn’t better than Agile. They are fundamentally different games. The methods and objectives are different.
      2. Although both sports have positions and specializations, Rugby players play in 100% of the game (pending injury substitutions), while Football players typically play 50% of the game. This is similar to Football where there is more specilization and subsituting of players.
      3. And perhaps the biggest difference – Rugby is a game more built on flow and reaction, where Football is built more on set plays that are planned and scheduled. (See where I am going with this?)

The point again should be that the games and objectives are different and that one game is no better than the other one.

Agile versus Agenda

My next thought was if we could find a nice, short term for Traditional like Agile that helped to convey the difference between Agile and Traditional like the analogy of Rugby and Football did.

When we look at the definition of Agile, we get:

“relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

It took me quite a while and lot of research, but I think I finally settled on Agenda. Agenda is a term I don’t believe I have heard used when discussing Sotware Development. When we look at the definition of Agenda, we get:

a list or outline of things to be considered or done

The important difference here is that an Agenda is a list with a temporal dimension. In addition, an Agenda is perceived to be an initial plan that is to be modified and added to as agreed to. In fact, the first item usually asked in all meetings that have an Agenda, is if the Agenda needs to be modified.

Perfect. Agenda Software Development. Like Agile Software Development, but with an initial planned schedule, outline, and temporal dimension.

Finally a term that conveys the accurate intent of Agile Software Development with a schedule. And that schedule is to be changed, modified, enhanced, and pivoted.

Yeah, Agenda Software Development. That’s the ticket. And in an Agenda Software Development project where Brett Favre, the gunslinger, is the Project Manager. Yea, that’s the ticket.

 

 

#PMO Visual Management Tools #PMOT #Agile

I have now been the Manager of the Project Management Office at the University for Manitoba for over two years. One of the first items I struggled with was trying to determine how to visually communicate the status of the portfolio of projects in a visual, intuitive way. I was a huge proponent of visual reporting and communication from my days as an Agile consultant. A textual or tabular report of the portfolio of projects just doesn’t inform stakeholders easily as to the breadth, depth, and status of the portfolio of projects.

Epiphany

Late one day, I had a discussion with our CIO in regards to how he had seen a radar diagram used as a means to communicate the life-cycle of Infrastructure within an environment. After a short discussion, we had formulated a plan as to how it could be used to display the portfolios of our projects.

We had devised a template to show the following:

  • Separate portfolio sections with
    • Projects represented by coloured circles of different sizes
    • Status of projects indicated by circle colour
    • Projects on hold indicated by a diamond
    • New projects shown by a distinct circle icon
    • Size of project indicated by size of circle
    • Indication of a project being over budget by a halo around the circle
    • Project phase indicated by the circle’s proximity to center of the radar
    • Project’s progress indicated by the circle’s overlay to show percentage complete

Results

The Portfolio Radar diagram has been refined over the months. but it is probably the most requested document the Project Management Office produces.

Recently, I have created a personal radar that I use to track my to-do items. Like a lot of managers, I usually have 10-20 items on the go that need periodic attention. These items can usually be categorized into 3-4 “portfolios”. The radar template is much more appropriate than the standard kanban board used for projects as the items can be recurring and of extended duration. Some of them can be standing items which are never really done. The “Personal Radar” is a great diagram for showing which items need to have attention paid to them next week and which ones can wait.

Like the Portfolio Radar, the Personal Radar indicates:

  • Separate portfolio sections with
    • Items represented by stickies
    • Urgency of attention indicated by stickie colour
    • Stickie phase indicated by the Stickie’s proximity to center of the radar

This “Personal Radar” for the PMO Manager has been a great assistance to stay of top of multitude of items required in the PMO. The Personal Radar gets reviewed at the start of the week to plan the week and at the end of the week to ensure the items received the attention they deserved.

So far, this is becoming a key deliverable to stay on top of items. An example of the Personal Radar is show below:

Summary

The Portfolio Radar and Personal Radar have been excellent diagrams to use for communication of project status and task management. I’d love to hear your experiences with other means of visual methods for Project Management and personal management.

Student of the Game #PMOT #NHLJETS @srogalsky @MarkScheifele55

As I sit down to author my first Blog entry of 2019, I reviewed my recent Blogs. Although I knew I hadn’t Blogged for a while, I wasn’t aware that I had not Blogged since July 2018. I had gotten quite busy in my new role of Manager of the Project Management Office at the University of Manitoba, but I was unaware just how busy I had become. So one of my resolutions for 2019 is to create a new Blog entry every month.

In hindsight, joining the University of Manitoba was one of the best career moves I have ever made. I have grown immensely over the last 2+ years and learned so much from colleagues both within Information Services and Technology and with external units and faculties. I would highly recommend the experience working in Higher Education. The people are brilliant problem solvers and the problems are complicated and have high impact. But that isn’t the reason for this first post of 2019.

Student of the Game

I was fortunate enough to have worked with Red River College during my career and was honoured to be invited to Keynote the BTM Tech mash-up they were putting on. All I had to do was come up with a topic! I talked about options with the organizers and we discussed presenting on how projects are managed at the University of Manitoba and how the work environment is different between Private Companies, Government. Consulting, and Higher Education. I still wanted something to leave with the students in regards to habits and practices of successful team mates. I eventually landed on a Student of the Game summary at the end of the presentation. I remember talking multiple times with Steve Rogalsky on the concept of Student of the Game, We both had felt it described a set of behaviours that were inherent in all the great team mates we had worked with. Even better I was going to connect it with Mark Scheifele for a Winnipeg Jets connection. I think I had a winner!

So what do we refer to when Steve and I mentioned team mates that were “students of the game”? I came across a great article “How to become a Student of the Game” by Anthony Iannarino. In this article, Tony makes the following three excellent points:

  1. Study the Fundamentals
    • The best performers in any endeavor spend a great deal of time studying the fundamentals. They read, study, and practice the basics. The best performers are willing to spend time on the plateaus, plugging away at the basics, even when it feels like they aren’t making any real progress.
  2. Make Distinctions
    • Reading, studying, and practicing are what allow high performers to make distinctions. They start to notice things. They notice things about themselves, and they notice things about others. They start to see how tiny changes produce outsized results.
  3. Teaching and Learning
    • The highest performers seek out teachers. They know that someone who has already had the experiences and made the distinctions can help them understand their own experiences and make their own distinctions. They’re excited about the prospect of someone facilitating their learning.
    • These high performers also learn by teaching others. The very act of sharing what you have learned takes your mastery to new levels. It means you have to think deeply about the how, what, and why something works.

Mark Scheifele

I then connected the concept of “Student of the Game” with Mark Scheifele and reviewed how Mark is a great example of being a “Student of the Game”

  • Selected 7th overall in 2011 in NHL Entry draft
  • Sought out Dale Hawerchuk at 17 to seek advice and counsel
  • Added Hall of Famer and skills coach Adam Oates to his off-season workouts
  • Attended Gary Roberts Summer Hockey Boot Camps every year for 6 years
  • Never swears on the ice – Respect for the Game

Summary

I added the connection to Mark Scheifele because of the concept of having Respect for the Game. This is something Tony did not mention but I think is critical for being a Student of the Game. The presentation even allowed me to connect the “Student of the Game” concept to the Agile Principles!

  • Continuous Learning
    • Find a Mentor or Role Model
    • Get on Twitter – follow other experts and read
  • Reflection
    • Review your work and others to spot opportunities
  • Collaborate and Learn from others
    • Review others work and practices
    • We are smarter than me
  • No Ego
    • Be respectful of others and their contributions
    • Understand that there are always things to learn and get better at
  • Be Brave to be wrong
    • Help to create a safe space to experiment

All in all, I think this presentation touched all the bases and it was very well received. I encourage you to read Anthony Iannarino’s article and watch a Winnipeg Jets game. GO JETS GO!

 

Top Three Rules of #Agile Software Estimation

Yep, Estimating is hard. It isn’t easy and it isn’t without peril. Unfortunately it is a fact on 95% of the projects we work on. So given that, I’m not sure that telling people not to estimate is productive. There are a lot of misinformation about estimating though. Not all estimates are evil and not all are a waste of time. Here are the three estimating rules that I follow that have served me well.

1. Estimate Iteratively

I can’t figure out for the life of me why people who discuss Agile projects assume that if you estimate you must be BEUF. (Big Estimate Up Front) I always estimate iteratively with the estimate getting more refined as I go along. Usually the stages are:

Proposal Estimate – At the very start of the process when you don’t know much

Plan Estimate – Creating an executable plan and estimate before you start after you know more about scope

Execution Estimate – Re-planning with the final team just before execution

Iteration Estimate – Re-planning before each Iteration

With an iterative approach to estimating you can provide a line of sight to the clients as to what they can expect and you can also communicate how the whole project will evolve. Even the estimates.

2. Estimate with the team

This is a no-brainer. Always, always, always estimate with the team. If your team composition changes, I would re-estimate with the new team. Friends don’t let friends estimate alone. It is as much a learning experience as anything else.

3. Estimate the Minimum Viable Product

This is probably the most important rule. Let me be clear. You have no business starting or being involved on a Software Development project if you can’t estimate that you can at least deliver the Minimum Viable Product. (MVP) Yes, I know it is hard and difficult and fraught with errors, but an estimation based on years of experience if better than no opinion at all.  It can save wasting money on a project that had no hope of success. And it doesn’t need to be a very detailed estimate at the start, just a high-level estimate that confirms the team believes it can be done. (see rule #1)

Some Estimating Falsehoods

There are some common Estimating Falsehoods out there. I have taken these from the Blog post on estimating by Matt Rogish that takes the point that estimating is harmful.

Here we go:

“In really terrible places to work, someone other than the developer will actually do the estimating. This estimate will then be given to the developer as an implicit (or at especially evil places, explicit) time not to exceed. This is such a depressing situation I cannot dare think of it further.”Correct. This is really a problem with bad leadership rather than estimating. Don’t throw the baby out with the bath water.

“Most estimation is drawn from past experience. What if the developer doesn’t have this experience? How can they estimate? This is where things get tricky. And by tricky, I mean “completely made up.” Sure, for things that have been done before by someone the developer can draw some parallels and make a guesstimate. But what about the stuff that has never been done before (presumably, the secret-sauce that makes you money)? Usually you just take a Wild-Ass Guess (WAG-estimation) and hope you’re not wrong. Given the rarity of being punished for under-promising and over-delivering this WAG tends to be a massive over-estimation.”This is a common Falsehood. As mentioned in Rule 2, no one estimates alone. Senior developers help the less experienced and share their wisdom. This point also again highlights just plain old bad management.

“Completely spec out the entire system ahead of time, spend a lot of time researching and estimating the problem, determine project dependencies, and you can determine the “finish date” before writing a line of code! It’s seductive and taps into the part of our brain that craves order and dependability.”See Rule 1 – Estimate Iteratively. I can’t imagine any Agile professional would fall into this line of thinking.

“If the value of software we’re writing is so low, is it worth being written? If the project has such tight time constraints that a schedule slip will doom the project then you’re in a world of hurt. (The solution is agile: work on the most important things first, have an always-working project, and cut scope to hit a date.)

This exposes a major weakness in most software companies: the inability to determine project value. Given a project of unknown value, the conservative business will then attempt to minimize cost. Unfortunately as we’ll see, cost minimization ends up becoming very expensive in the long run.”This is a strange point to me. We as software developers can’t estimate our projects, but YOU the business need to estimate the value. Well we can’t have it both ways. I agree Agile is the solution, IF we estimate we can complete the Minimum Viable Product within the current budget. See Rule #3.

I’m not entirely sure what this means, but I’ve never seen the folks who are writing the specs, requirements, etc. ever being asked to estimate how long each spec will take to write. Or have the CEO give a date when the company will hit some arbitrary metric, although see the perversity in public company earnings estimates and reporting.”I’ve seen both on all the projects and companies I’ve worked for. CEO bonuses are commonly tied to unrealistic estimates on an arbitrary timeframe.

“Ultimately companies require estimation because they don’t trust anyone. They don’t trust developers to deliver results. They don’t trust mid-management to motivate their reports. The underlying reality is that the folks “in charge” are worried that everyone is going to rip off the company and only by holding people to arbitrary deadlines are they assured stuff will get done.

Committing to a date allows them to sleep better at night and shifts the blame from them to the folks on the front lines. “Wow. If anyone works at a place like this, leave. But don’t blame the estimates. If you don’t produce estimates, this company will just find another way to pull a fast one on you.

“Estimation is ultimately a futile effort. Software, more or less, is like writing poetry. Or solving mathematical proofs. It takes as long as it takes, and it’s done when it’s done. Perfect, or imperfect, estimation won’t change how long it takes to complete the work. If that sounds horrible to you, then go do something else.”I could not disagree more. It is correct that estimation won’t change the amount of work it will take to complete something, but that isn’t the point. The point is about giving some imperfect information to the client to help him/her make business decisions. You remember the client right? The one who is going to pay the bills and we are trying to deliver value to right? I would agree that truly unique software solutions are like writing Poetry. I was on a R&D project recently and the estimating was challenging to say the least. But 95% of Software Development projects are following semi-established patterns. The projects are not routine, but nor are they like creating something fundamentally new all the time.

“Estimation actually slows down development because estimation isn’t free. The developer is incentivised to take as long as possible estimating in an effort to not get beaten when they miss the estimate. Why waste that time when the metric the developer is attempting to hit ultimately generates negative value?”See Rule 1 on estimating iteratively and this is just an example of bad management once again.

Summary

Estimation is difficult, never correct, and is fraught with danger. But if you are like me, the vast majority of my clients require them. So the question is not why can’t we stop doing estimates?,  but rather how can we do them better?

In almost all cases, the problems with estimating can be traced to bad leadership on management. That is where I believe our focus should be.

Project Choreographer – an Agile Project Manager

In the last few posts I have had on Agile Project Management, I’ve continued to struggle with what term to use when referring to an Agile Project Manager. Here are my thoughts:

  •  I really don’t like the Project Manager term as it implies that the team needs to be managed at a very low-level.
  • I didn’t like Project Leader as it implies that the team needs to be led and can’t provide the leadership themselves.
  • I don’t even want to talk about the Scrum Master term. It implies that the Project Manager just oversees the process and I dislike the ‘master’ terminology, but maybe that is just me. 🙂

I also wanted have a term that re-inforced the that Project Manager contributes more to a project that just the maintenance of the budget and schedule. That he or she is really an experienced practitioner that understands the business of developing software. I was really searching for a common term that would communicate all these roles and responsibilities without the negative connotations.

So what is the proper term that provides a valid description on what an Agile Project Manager does? May I present…

Agile Choreographer

I found an excellent article on Ehow that listed the duties of a Choreographer. Upon review I updated it slightly by primarily making the following substitutions:

  • Choreographer –> Project Choreographer
  • Dancer –> Software Developer
  • Performer –> Software Developer
  • Dance –> Project
  • Dance steps, routines –> project routines
  • types of dance –> types of projects

With these changes and some additional minor ‘enhancements’, this is what I ended up with:

Project Choreographers

Project Choreographers are experienced Software Developers who have acquired excellent reputation as developers. They have many years of training, preferably in more than one style of development. They may have obtained a bachelor’s degree or a master’s degree in Software Development, but talent and ability are more important. They can live and work almost anywhere, as long as there are projects in the community.

Planning and Creating

Project Choreographers plan original projects by combining a variety of project routines. They might modify existing projects. Alternatively, they may develop new interpretations of traditional projects. Some Project Choreographers may decide to focus on a particular type of project. In the majority of cases, however, they are expected to work in all types of projects. A few Project Choreographers specialize in the particular methodology or routines that comprise a project.

Mentoring

Project Choreographers are often present at interviews and provide input into the selection of Software Developers. Once projects start, they teach the choreographed project routines to the team and make the necessary modifications to the project. They must be able to communicate and teach all types of project routines and also collaborate with the team. Because few of the project routines are written down, Project Choreographers often demonstrate the exact techniques. It is important for them to stay flexible and keep up with the latest trends in the project routine field.

Meeting and Promoting

Project Choreographers must also possess excellent communication, teamwork and time management skills. They meet regularly with the Client, Sponsor, and/or team to brainstorm and solve any problems that may arise. They may be asked to help promote the project by presenting.

Summary

I certainly think this description is quite close to the intent of an Agile Project Manager. At least it is very close as to how I like to manage Agile Projects. Although it may not be feasible for people to use the Project Choreographer term instead of Project Manager, I think it communicates the intent of the role much better.

If you are interested, you can find the original article on Choreographer Duties by following this link.