Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?

InstantPot_Bitcoin_MachineI am excited to be presenting at next week’s PMI-SAC Professional Development Conference on May 2 in Calgary. I am looking forward to seeing old friends and meeting new people at this new format conference.

My session “Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?” examines the hype, realities and use of agile approaches.  Here is the presentation summary from the conference site:

“The project world seems to have gone agile mad. The PMI has stuffed agile into everything in an attempt to stay current, but is it right or even helpful? Fear of missing out has vendors claiming to be agile and executives asking managers to be more agile. However, like InstantPots and cryptocurrencies, does the reality live up to the hype?  This session investigates the agile trend and looks at a new breed of agile suitability filters that help organizations apply agile approaches only when and where they make sense.

The presentation profiles organizations that effectively use agile approaches and how to build PMOs that support agile, hybrid, and traditional project teams. We look at the limitations and applicability concerns of using agile approaches. It would be naïve and arrogant to believe that agile (or any other approach) is universally the best way to execute projects. So, what types of projects do suit the approach (spoiler alert: novel, knowledge-worker projects) and what types of projects should best avoid it?

We will explore hybrid approaches where certain portions or periods of the project can exploit agile approaches. In these hybrid scenarios, we examine how to coordinate and integrate the agile work with the more traditional, plan-driven work. Also, we will examine the cultural fit of agile approaches and investigate how corporate mindsets and values effect structures and decision making. Trying to force fit a new mindset that is at odds with the corporate culture will inevitably be met with resistance. So, we need to be smart about what we try to introduce and how we plan to do it.

Our end goal should be successful projects and happy stakeholders. The approach we take should be appropriate for the tasks at hand, there are no points for style or conformance, since every project is different. So, learn how to analyze the project variables that include organizational, standards, technical and team components then act intelligently within that framework also guided by the inputs of the contributors.”

That description was for a 2-hour slot proposal and I was assigned a 1-hour slot so I will have to cut some material, but I will cover the highlights. The presentation title and outline are deliberately a little controversial to hopefully spur some reaction and interest in the session.

Having been involved in the development of the recent PMI standards, I personally do not believe “PMI has stuffed agile into everything in an attempt to stay current”, however, I can see how this may appear so to external parties.

As agile rides the hype cycle it is important to retain a grasp on where it can add value and where it’s use should be limited. This session aims to strip away some of the hyperbole and ground people with some practical application tools. Please come say hello if you see me at the conference!

PMI-SAC PDC Banner


Where Did All the Project Managers Go?

PuzzleSoftware is eating the world” claimed venture capitalist, Marc Andreessen in his 2011, New York Times article. Seven years on, the trend continues, and project managers are also on the menu. The next generation of project managers face new challenges but also new opportunities as organizations undergo a major transformation.

Software is becoming omnipresent, it is embedded and integral to all industries. Not just technology companies (like Google, Apple) but every sector is being disrupted by software including retail (Amazon), banking (PayPal, cryptocurrencies), transportation (Tesla, Uber), and travel (Airbnb).

As a project manager you may say “Great, just think of all those IT projects that will need project managers!” Well, that’s where things get interesting. First, today’s software teams don’t respond well to being “managed”, that’s old-school command-and-control thinking along with Gantt charts and calling people “resources”. Instead, they are led, empowered and supported by servant leaders. Next, the idea of a “project” with a defined endpoint is dissolving too.

As organizations realize their software systems provide the competitive advantage then stopping development equates to an end to innovation or competing. When organizations become more software-driven their systems are never “done”. As a result, organizations are switching from projects (that have a fixed end) to products - that continue to evolve. This movement popularized by the #NoProjects and Continuous Digital titles is growing exponentially.

 

 The Project Manager in a No Projects, No Managers Future

This double whammy of no more projects and no more managers likely creates heartburn for people with the job title “Project Manager”.  While this trend is clearly the future of work I believe there will always be a role for smart, cooperative people that can help with collaboration and development. 

 A quote that comes to mind is “The more things change, the more they stay the same.” by Jean-Baptiste Alphonse Karr. The next generation of project managers will have new titles like “Product Leads”, “Development Team Coordinators” and “Digital Transformation Leaders”. They will help organizations build development capabilities around long-term products.

 This new generation will still communicate with stakeholders about status and risks. They will still facilitate consensus gathering amongst experts. They will still try to diffuse conflict and find common ground during arguments. The goals (satisfied stakeholders and value delivery) will remain the same but the tools, titles and processes employed will be vastly different.

 

New Tools and Approaches

Heavy upfront planning efforts and the use of tools like critical path network diagrams and PERT charts are not so useful when the input data is very uncertain. Tools like work breakdown structures offer great insights into sub-system assemblies but they are slower and more difficult to reprioritize than modern backlogs and release roadmaps.

As rates of change increase so too does early lifecycle uncertainty and the competitive need to start work quickly. The days of carefully analyzing work products upfront are dwindling. Instead, organizations build prototypes based on what they know right now and then iterate towards the final product. In the intangible world of software, the cost of experimentation is less than that of detailed analysis.

Also, using a software product provides better feedback on its suitability and possible expansion than reviewing a document or diagram about it. IWKIWISI (I Will Know It When I See It) becomes the new mantra, replacing the “Plan the work, and work the plan” ideas of old.

As organizations adopt a continuous delivery model that is focussed on products not projects then funding models change also. Instead of yearly budget cycles to fund entire projects, smaller tranches of funds are released to create a Minimum Viable Product (MVP). Then, providing the product continues to return value, more funding is made available. A venture capital funding model lets product leaders focus on delivering a stream of high-value features that support continued investment.

Projects classically track metrics like on time/budget and Return On Investment (ROI). Products track customer satisfaction, market share, profit to funding ratios. They are similar concepts but a new vocabulary to learn.

 

Role Changes

Agile software development teams organize their own work, solve most of their own problems, and are empowered to experiment with new work strategies and approaches. They do not need (or want) to have work assigned to them, nor asked to report status. Instead, they make their work visible via kanban boards and new features.

They do however need people to remove impediments and chase up external dependencies. They also need investment in training, shielding from interruptions, plus regular encouragement and words of thanks to stay motivated. In short, all the servant leadership practices that good project managers did anyway still apply.

Project managers cannot be the center of work planning or task distribution. There is too much complexity to be anything but a bottleneck. Instead, we must trust development team members and product owners from the business as subject matter experts in their own domains.

Where these teams often need help is keeping the larger perspective on where it is we are trying to get to. When you are heads-down on solving a technical issue, it is easy to lose sight of the end goal. Having someone communicate the product vision reveals a beckoning summit towards which others can chart their own course.

In this way servant leadership and visionary leadership that predate modern project management are still valuable and needed. Yet the scientific project management that grew out of the industrialization of process is largely left behind.

 

The Future

In many industries, the classic role of projects and project managers will continue. I don’t see construction moving away from big upfront design and the reliance on project managers any time. In the software world though I think we are heading for substantial changes. Sure, some companies will continue as they always have with software project and project managers. However, most organizations will transition to long-term products with leaders and coordinators.

It is an exciting time for life-long learners willing to acquire new tools and approaches. There is no shortage of work for people who can collaborate with others and solve problems. The critical role of software will increase as organizations undertake digital transformation and adopt continuous digital strategies based on products vs projects. So, while the role “project manager” might be heading into the same category as “switchboard operators”, “human alarm clocks”, and “bowling alley pinsetters” the work and opportunities in this exciting field continue to grow.

[I first wrote this article for ProjectManagement.com here]


Government Lessons in People Over Process

CubicleMy first opportunity to create and run a large agile team did not start well. Having had good successes with small to medium sized agile teams I was keen to unleash the benefits on a bigger scale. I was working for IBM at the time and was able to persuade my account manager to pitch the approach on one of our government projects. A clean-sheet development opportunity with a smart team and engaged business group – what could go wrong? As it turns out, plenty due to my ill-advised approach.

It was the early 90’s and we were trialling techniques that would later become the agile approach DSDM (Dynamic Systems Development Method). Taking ideas like James Martin’s RAD (Rapid Application Development) and active user involvement from Enid Mumford’s Participative Design Approach, we had already dramatically reduced development time and improved acceptance rates on several projects. I was convinced collocated teams with short iterations of build/feedback cycles were the future. We were all set for a big client success and who better than the British Government for good publicity! My enthusiasm was about to be tested.

I was given a full rein of the project, or as I would later realize, just enough rope to hang myself with. Having struggled to get dedicated business input on previous projects I commandeered a large boardroom to collocate the development team and business subject matter experts (SMEs). It was awesome, everyone was together in one room and we had direct access to the business representatives for requirements elicitation, clarification, and demo feedback. We were working hard and getting lots of features built but the business representatives hated it.

At first, I thought they hated me. I think that is a common mistake, we internalize changes in behaviour as attacks or criticisms of ourselves. What have I done? What did I say to upset them? - all of them! I recall wanting to write on my internal project status report to the IBM PMO that “the business is revolting”. However, that is what occurred, starting as cordial and helpful, the business SMEs became less helpful, then uncooperative, and finally hostile. I had a revolt on my hands that I did not understand.

This was my first introduction to organizational change. Luckily for me, I had access to many people in IBM smarter and more experienced than I was. I was given a book called “How to Manage Change Effectively: Approaches, Methods, and Case Examples” by Donald Kirkpatrick that changed my career. In it Kirkpatrick outlines circumstances where people will resist change. These include:

  1. When people sense loss in: security, pride and satisfaction, freedom, responsibility, authority, good working conditions, and/or status
  2. It creates more problems than it is worth
  3. Extra efforts are not being rewarded
  4. Lack of respect for those initiating the change
  5. The change initiative and its implications are misunderstood
  6. Belief that the change does not make sense for the organization
  7. Change is misdirected, current state or alternatives are better
  8. A low tolerance for change in our lives
  9. When change violates a principle or commitment that the organization must stand by
  10. Exclusion from the change initiative
  11. Changes viewed as criticism of how things were done in the past
  12. The change effort occurs at a bad time, other issues or problems are also being handled

Something I was not aware of at the time is how the career development process works within the government. The most junior new hires work in open-plan cubical offices. Then as you get a promotion you get moved to bigger cubicles with higher walls that are more like mini-offices. Next, you get promoted to a real office, then an office with a window, and eventually a corner office. In short, your workspace defines your status, responsibility and authority.

By bringing these business representatives into a shared boardroom to work on the project I had unwittingly generated change resistance scenarios 1-3 and probably triggered many others also. Making them sit and work together like the most junior recruits had caused a loss of good working conditions, status, freedom, pride, satisfaction, and perceived authority. A bad idea when hoping to develop a productive working relationship with someone.

Luckily for me the Kirkpatrick book also lists circumstances when people do accept change, which unsurprisingly are the opposite conditions and include:

  1. When change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, or achievement
  2. Provides a new challenge and reduces boredom
  3. Opportunities to influence the change initiative
  4. Timing: the time is right for organizational change
  5. Source of the change initiative is liked and respected
  6. The approach of the change and how it is implemented appeals to us

So, equipped with these ideas we changed our approach. Instead of the business SMEs being collocated with us they returned to their fancy corner offices, long lunch breaks, and afternoons spent reading the newspaper - none of which they could do when they all sat together. Instead, we reserved their mornings for questions, review sessions, and demonstrations. This was better received because their morning calendars were blocked with important project meetings, but we rarely called on all of them at once unless it was for a business demo.

Now they had their offices back, a little more free time, and were engaged in a more respectful way. The team were sceptical at first. However, it really is much better to have one hour of someone who is cheerful, engaged, and helpful than eight hours of someone who is bitter, obstinate and causing issues. The project went much smoother after these changes and it taught me an important lesson in never trying to introduce a process or practice without considering the people elements first.

We completed the project early, largely due to the input and hard work during acceptance testing of the business SMEs, and IBM got their successful case study. I learned to temper my enthusiasm and consider other stakeholders who will undoubtedly have a different view of the project than myself. Individuals and interaction are indeed more important than processes and tools, even if they are your own pet agile processes and tools.

[I first wrote this article for the Government themed November issue of ProjectManagement.com, available to subscribers Here]


The Importance of Focus

Edison BulbI have an old-fashioned Edison bulb desk lamp. It’s to remind me to focus (and because I like steampunk, industrial design). A 40-watt incandescent bulb will barely light a room, but a 40-watt laser can cut through aluminium, leather, and wood. It is the same amount of light energy, just focussed instead of being diffused.

The same principle applies to our attention, work and teams. Diffused and scattered there is not much impact. Focussed and concentrated that energy is very impactful. Removing distractions and focussing on a single deliverable at a time allows us to complete our work faster with fewer defects.

Aligning a team to a common vision and purpose directs their energy towards it. No longer diffused to fulfil a dozen competing demands, effort is channelled to the shared goal. Distractions come in many forms. Fancy tools, cool architecture, requests from different groups. If we do not pay attention to focus, our laser beam team becomes an Edison bulb, it is busy and glowing, but not very effective.

So, be cautious of distractions. Monitor time and energy directed to the project goal compared to energy directed to peripheral activities. Work life is like a greased pole with a 40-watt Edison bulb at the bottom and a 40-watt laser at the top. We must always be striving upwards to focus because as we relax we slide down towards distraction.

(Also visible in the picture is my “Do The Work” Post-it. another reminder to focus and a pointer to work on the same topic by Seth Godin and Stephen Pressfield. I guess I could get a 40-watt laser too, but that would scorch the cat rather than amuse it. Plus yes, it is snowing here and yes, my windows are old)


They are “Lessons to be Learned”, not “Lessons Learned”

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

  1. Concrete Experiences (What we already know)
  2. Observation and Reflection (What our retrospectives help us identify)
  3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
  4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know. Experimental Learning Cycle

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead useLessons to be learned”.