Ole (one of our Solution Architects) lines up his shot
This month, our team headed to London for the June 13-14 Gartner PPM & IT Governance Summit. Gartner is a technology research and analysis firm that advises enterprise clients. They are considered by many to be thought-leaders for management and IT.
The theme of this year’s summit was “Results-Driven PPM — Leading Change and Delivering Value in the Digital Age.” In our opinion, Gartner’s key message was that, in today’s rapidly changing business world, organizations need to develop the capability to quickly react to change and focus on value delivery, rather than continue to focus on managing budgets and meeting deadlines.
This theme matches perfectly with our tool, so we decided to become a sponsor of the event and demonstrate our agile PPM and SAFe capabilities. The summit was full of executives and analysts, all sharing knowledge and trying to find the next big thing. We wanted to gather feedback from this high-level crowd, and examine our own position in the PPM market.
Learn how to connect strategy and execution in the PPM section of our Solutions Gallery
The Targetprocess Booth:
Our booth’s theme was “Work smart, golf more.” The idea behind this is that using Targetprocess for agile portfolio management (agile PPM) will allow PMOs to save time by improving visibility and traceability. You can read more about this concept at our online brochure.
There was a lot of excitement at our booth about agile PPM, as well as the possibility to manage ALM and PPM in one singular tool. However, there was also some disappointment about the lack of certain traditional items, such as Gantt charts. We’ve said before that timelines are better than Gantt charts for agile management, but we still paid careful attention to these criticisms (see our conclusions at the end).
After a day of serious presentations and keynote speakers, we took part in a networking reception and handed out some golf-themed drinks (‘Tee’ Time, “Hole in One”) as well as golf balls with agile PPM quotes. We also laid out a small golfing mat in front of our booth and even dressed up like golfers, just for a bit of fun.
Visitors to our booth had the chance to win a set of Wilson golf clubs. At the end of the summit we held a lottery, and Maria Kiekara from YIT Group was drawn as the winner. Congratulations Maria!
Our team members came from London, Germany, Belarus, the Netherlands, and the U.S. to be present for the summit. The photo was taken after an evening Networking Reception on June 13, 2016
On business in general:
Gartner states that digital business is still evolving, and predicts that algorithms will be used in autonomous business with smart machines through 2020 and beyond. Just as the internet brought about the advent of digital business, algorithms and smart machines will be the catalyst for algorithmic (or, autonomous) business.
Gartner PPM & IT Governance Summit, 13-14 June 2016, London, UK, Keynote: Business and Technology 2030: Algorithms and (More) Autonomous Business, Dale Kutnick, Donna Fitzgerald
Gartner is continuing its advocacy for Bi-Modal IT, a practice that Gartner defines as the “the managing of two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.” Analysts stressed the need to dedicate resources to Mode 2 projects without traditional budget rules:
- The value of Mode 2 initiatives are not easily reflected using traditional ROI analysis
- Mode 2 projects which are subjected to traditional funding and governance rules will be stymied, often at the expense of innovation
- Creative leadership from the CIO and IT departments is required to shift the thinking around approval and funding for Mode 2 projects.
Gartner PPM & IT Governance Summit, 13-14 June 2016, London, UK, Workshop: Mode 2/Agile Funding — No Longer, About Cost But Value, Jim McGittigan
Gartner PPM & IT Governance Summit, 13 - 14 June 2016, London, UK, Changing Governance to Exploit Enterprise Agile, Bill Swanton
The unfortunate truth about agile is that it is excellently positioned for use as a buzzword. However, we know that agile should be more than just a buzzword and is here to stay.
Gartner PPM & IT Governance Summit, 13 - 14 June 2016, London, UK, Survival Strategies for the PMO in an Enterprise Agile World, Matthew Hotle
This year, a recurring theme at analyst presentations seemed to be that traditional project management should give way to agile product management. Early capability to ship value (as MVP), continuous improvement, iterations, and team continuity were some of the cited benefits that such a shift can bring.
Gartner discussed SAFe as a framework for scaling agile practices.
We believe a key message from Gartner was that traditional PPM is still widespread in the enterprise market, but PMO's and CIO's need to figure out how to embrace agile at the enterprise level.
Gartner PPM & IT Governance Summit, 13-14 June 2016, London, UK, The PPM Market: State of the Universe, Daniel B. Stang
Gartner also stated how digitalization is disrupting the PPM “Comfort Zone.”
An action plan from Gartner for PPM Leaders: In the next 12 months, work to eliminate or consolidate overlapping tools where possible, without assuming all work can be managed in one tool.
Gartner also offers some advice on PPM tool best practices in the face of disruption: keep track of the varied needs for different kinds of PPM tools, listen to the different workgroups and teams asking for them or adopting them outright, and don't assume you can force all the workgroups into the same tool.
Gartner PPM & IT Governance Summit, 13 - 14 June 2016, London, UK, The PPM Market: State of the Universe, Daniel B. Stang
There was a lot of discourse about agile at the summit. Still, we observed that many of the exhibiting tools were fairly traditional, and the attitude of PMO representatives from some companies towards agile seemed to be one of guarded optimism.
This caution is understandable; the enterprise market is just waking up to agile as the way to survive in today’s disruptive economy. The PPM industry is going to need to reinvent itself soon to stay relevant, but big enterprises cannot just switch gears as fast as they may want to. However, companies that adopt an agile mindset early-on can expect to get a leg up on the competition as the digitalization of business pushes inexorably forward, forcing companies to adopt more flexible and adaptive approaches.
"By 2020, more than three-quarters of the S&P 500 will be companies that we have not heard of yet." - Professor Richard Foster, Yale University
We're not saying that Targetprocess, as a tool for agile portfolio management, is the ultimate solution for any client. Just as agile can't be looked at as a magic pill to cure all your troubles, no software tool should be looked at as perfectly comprehensive for all 4 levels of Gartner's pyramid above. Our PPM solution is still evolving. However, we strongly believe that it is well-positioned to help companies that want to scale agile to the enterprise level in order to embrace change, become more responsive, and deliver value faster.
As a nice bonus, Targetprocess lets you do both agile PPM and agile ALM within one tool so that you can have more time for other activities, such as golf (instead of manually synchronizing data between your PPM and ALM solutions). Speaking of which, we have some Targetprocess golf balls left with quotes about our PPM solution, so let us know if you feel like giving it a shot!
The concept of Minimal Viable Feature (MVF) is a significant milestone in product development. Release something that you think solve a problem and listen for the feedback. While the concept itself is great, the devil is in the details. In general, it is quite hard to learn how to define MVF. It is an art, not a science. In this article I will share my experience and some patterns I learned.
#1 Cut. The. Scope.
The most common mistake in MVF definition is bloated scope. There is always a desire to put one more thing into the feature and make it more useful and more appealing to the end user. No Product Owner can resist this intention and in almost every single feature I lead I added some unplanned user stories. In fact there is nothing bad with this approach, you discover new information and change plans. However, there is a real danger to push feature beyond MVF and delay its release. 9 months feature? We had it in our company.
Now we have a 3-months rule for every MVF. There should be serious reasons to spend more than 3 months on MVF implementation. MVF goal is to prove concepts and discover "unknowns", don't blow it to MMF.
#2 Feature kick start
Everybody should understand why we add this feature into a product. There is only one reason to add a new feature — it solves some important problem that quite many users face quite often. In the simplest case you have hundreds of requests that picture problem in bright colors and all you have to do is invent a solution. In a more complex case users don't fully understand the problem and throw out various solutions that in fact don't solve this particular problem. Only experience and system-level thinking can help to spot such cases. In the worst case you have no feedback and rely on your intuition to define the problem. This is a dangerous practice that can lead to extreme results: genius insights or total fuck-ups.
On a Feature Kick Start meetings we have people from marketing, development, testing, design and sales. All bring valuable information about various facets of the problem.
These meetings have several goals:
- Clearly define the problem we solve.
- Define a scope of MVF.
- Decide what we don't know and what feedback we will accumulate now and after MVF release.
- Bring development team and sales people to a common understanding about the feature.
#3 Huge upfront UX is bad
We tend to have UX and Development as a completely separate activities. Sometimes we spent months on a feature UX, built prototypes, tested them and then boom... priorities changed and feature is no longer needed so much. Almost all the time we spent was just a waste. Let's say we get back to the feature next year, but now we have new information and UX we did a year ago is obsolete now, so we have to start over again.
Now we start UX when feature is actually starts. It means Feature Team almost completed previous feature, so it has some spare time to dig into the new feature and discuss its design, flows, etc. It may happen that developers don't do much for some time, since UX is not ready. However, there are often many things they can do: fix some old bugs in background, prototype new feature, try some technical and architectural ideas, implement something we 100% certain about. So while in theory it looks like you are not "utilising 100% of resources capacity", in practice single-feature flow for a Feature Team shortens cycle time and reduced waste activities.
#4 MMF is inevitable
Usually MVF solves a part of a problem and some cases are missing. Usually the solution itself is not the best. In most cases MVF is not a "complete" feature and you should finalize it. We call this finalization Minimal Marketable Feature (MMF). At this point feature provides a complete solution to a problem, the solution itself is beautifully designed, it is on par or outperform similar solutions in competitive products.
It may happen that new feedback will reveal that MMF is still not enough, so then you can iterate and release as many improved features as you need. This process is not formalized in our company.
#5 Real feedback is slow
We hoped to have 2-3 weeks delay between MVF and MMF and we thought it will be enough to accumulate enough feedback. We wanted to have process like that:
However, in most cases it takes 2-4 months to generate good amount of relevant feedback. It takes time to accumulate and reveal common patterns. For example, we re-designed navigation and allowed users to create their own Groups and Views inside these Groups (BTW, it was the case when we throw out UX done 9 months before feature start). It took us 5 months to actually understand what mistakes were made and what problems most companies have with this new flexible navigation. It appeared, the navigation was too flexible, so now we are reducing this flexibility and add some restrictions.
We changed the process and now we plan for 3 months delay between MVF and MMF. This gap is used by another MVF, so on a high level we release first minimal feature, that release second minimal feature and then based on generated feedback we complete both features.
#6 Real feedback comes from real usage
Don't get me wrong, I'm not against prototypes, wireframes sharing, surveys, etc. However, my experience showed that the only way to get a really relevant feedback is to release something in a product. All other ways of feedback generation are flawed. Real users bring so many unexpected and interesting insights.
When we started UX process adoption on our company 6 years ago, we tried almost any possible way of feedback gathering. We created several solutions to a single problem and run usability tests, ran surveys, interviewed customers, ran UX groups and shared concepts and ideas. We still use most of the methods from time to time, but our current approach is extremely lightweight and balanced. In general, we build light prototypes only when we just can't select a solution from two options (50/50 votes inside our team). We never build full interactive prototypes that replicates future system behavior, but just share sketches and main concepts. With right questions asked this simple method allow us to get a very nice preliminary feedback.
- Set clear MVF goal and cut MVF scope that beyond this goal.
- Bring sales, marketing, development and design people together to define MVF.
- Huge UX phase upfront is bad and usually leads to waste.
- MVF is not a full feature. Embrace it and don't rush.
- Real feedback comes from a delivered feature only.
- It takes several months to accumulate information to reveal patterns and decide how to improve feature.
The more I explore how IT organizations work, the more I see how strikingly diverse they are. They are as unique as human beings. Each organization has its unique process, unique culture and unique service or product that they deliver. On the surface, it might seem that businesses can be broken down into categories, e.g. a small or a large, a production or a service company, and there's indeed a certain similarity. The big "but" comes into play when an organization wants to achieve some outstanding goal, e.g. increase sales by 300%, or cut down the time to production by 50%. There's no such thing as similarity then. Small things in which companies differ then gain the last-drop power for a breakthrough to happen. The uniqueness lies in custom mixes of organizational culture and production process. Unique goals require unique ways to achieve them. I will use software development industry as an example to illustrate one striking phenomenon that holds they key, the Holy Grail to getting things done efficiently in unique organizational contexts.
Solve a Unique Problem by Copy-Pasting a Solution? No way.
At various phases of their lifecycles, organizations have to address their unique challenges. What do stakeholders usually do first as they encounter a problem? One disturbing commonplace trend that I've noticed is to replace addressing the root of a problem with a trendy buzzword model or management technique, and rely on it thinking: "Once we implement this super thing in our company, all our problems will be resolved." Or, if the Super A..buzzword technique is implemented, and brings no results, stakeholders keep staying in the limited stalls of prescribed buzzwords, and then that's what they think: "Hmm, the Super A.. thing is not working. How about we try a Super K... thing?" I've written about that in my previous articles on agile, Kanban and Big Data, as I looked at their origin, and on how they play out in the long run. It could all be very well if this approach with sticking, or switching, to one coined technique or another helped in 100% of cases. That's not true, however. It seems that most organizations have slid from the ruthless clarity of a simple "why?" to juggling boxes filled with loud labels for what some time worked for someone. Thinking is the hardest job, and with the amount of cognitive loads that we, Homo Sapiens, experience these days, organizational stakeholders are tempted to use shortcuts and grab the leash of what a mega-guru has said should be done. *Totally forgetting that the mega guru probably used this technique or a tip for an organization that is completely different from yours*.
Which consequences does this habit have on a larger scale? Trying to fit a unique context of an organizational challenge to a limited set of Super A.. or Super K... techniques is an attempt in futility. If there's some fat on the belly, that is, if this organization can afford paying for such abstract things as "measuring agility" (???), then the stakeholders would hire a consultant to translate the language of how things work in their organization to a lingo of a Super A.. technique, and/or will send their employees to be certified in this new religion, and/or introduce some ridiculous measurements that would serve it. Such reality shows are ubiquitous, and the following lame syllogism crowns them: "We are going Super A.. now, so we need a tool to call ourselves truly Super A..." or " Hmmm... Super A.. does not work for us. The sales are not higher, and we do not have faster turnaround times, and Super A... is not helping us find out if what we are doing is actually right or wrong for our organization if we want to hit this target. Hmm. They now say a lot about the Super K.. technique. Yes! Let's try it. Let's switch to Super K.. and, of course, we want to be truly Super K.. so we need a tool for that!"
The Health Check: 5 Why's and 6 W's
The quickest health check is to ask the 5 Why's. Why are we doing this? If the name of the Super A.. will still linger in the answer to your very last 5th "why", you can probably throw the super A.. to the trash bin. Your organization needs to deal with real things. Not with the labels in a toy store. The other health check is the 6 W questions technique (What? Why? Where? Who? When? Which?) applied to what you have in plan for projects and processes. As a side note, I don't care from which buzz management Super XYZ lingo the 6 W's and 5 Why's originate (and, yes, I do know of Six Sigma). These are the simplest bulls..it detectors to verify the actual worth of an approach to management.
It breaks my heart to read articles and blogs on software development written exactly with the Super Whatever shallow mindset. I can't stand looking at how limited thinking prevents people from grasping the uniqueness of their challenges and addressing them effectively. I can't stand looking at how the loud name of "methodology" is haphazardly glued to the how-to techniques and practices that worked only for certain organizations. And, I've explored the reasons for that thing happening in one of my previous articles. The education that IT professionals receive is too narrow. It doesn't allow them to look beyond how-to's too much, as they are not even trained to look beyond the how-to's. The how-to approach works for coding, or for dealing with mechanisms, but it doesn't work for organization/product/project management. I'm humbly hoping that my articles help to provide broader and deeper perspective, a perspective that someone might need to fix things gone wrong in their organizations.
Back to my intolerance to the evil reign of how-to's and to the habit of their copy-pasting. This habit is even more dangerous than smoking or drinking, because with these everyone knows they are bad habits, while with the how-to's abuse, people keep thinking that if everyone else does it, then that's OK.
Pragmatism is Dead, Long Live Pragmatism!
It's time to regain justice and call things their true names. Let's retrieve one precious treasure from the chest of eternal wisdom and blow the dust off of it. The treasure that lies there abandoned has this written on its plate:
A methodology is a school of thought, and a method is a way of doing something.
In other words, practice is the only criterion for truth. On the meta-level, this reasoning is backed up by the philosophy of pragmatism. However, there can be a shallow pragmatism and a smart pragmatism. A shallow pragmatism, briefly, is a short-sighted plan and course of actions, while smart pragmatism is something that I've written about in the article Visualization: Why the Fusion of Arts and Tech Matters.
The smart pragmatism, for software development, occurs when the blind sages touching various parts of an elephant recover their sight and realize that all of its parts function as a whole. Often organizations held their internal mini-wars, especially as they grow, between marketing teams and production teams, as they divide the spheres of responsibility between many decision-making groups, and when those parts have to merge, it feels like flying through the rough air. The head does not know what legs and arms are doing, something of that nature.
I want to make null and void any methodologies except "use your guts". There's no such thing as a success of a one part. Success comes as a whole, and for that success to happen, unfortunately (or fortunately), there's no other way as to think outside-the-box, sometimes even forcefully blocking the trendy how-to's. One can read tons of books, or follow gurus, or "best practices", but these activities are secondary as compared to independent thinking. Sometimes, it's a surprising and a pleasant side-effect to discover that you have arrived to the same conclusion as some renowned guru did, but by yourself, in your practical context. And this is a lot more precious and effective than copy-pasting a technique with no deeper understanding. That's why, if you have no guts — grow them. If you have guts, but you're too tired, get some rest and restore your ability to think independently and clearly.
No Need for Ninjas, but Let's Call This Thing Somehow
The use-your-guts pragmatic methodology does require a method (a way of doing). I've checked on most of the methods used in software development. Some of them have common sense in-mixed with limiting prescribed practices (see my article Stuck with Kanban? Consider Multiban). As you might have guessed, I have invented a method that is based on Kanban, but differentiates from it in the core "way of doing ". And, although I'm quite skeptical about using new names for what appears to be clear, I still have a name for that method: Multiban. This word is a Japanese-English mixture, and means something along the lines of many boards, many views and many perspectives. This name will stick in the memory, as it implies connection with Kanban method, with one important update. While Kanban uses cards as static signs for work items only, Multiban uses cards as dynamic signs for any abstract or concrete entity. Multiban is a visual management method (see and use your guts) that has no prescribed practices. All Multiban wants are custom visual representations, multiple 2D views of crossed rows and columns, that support whichever perspective to power your thinking. Why I deemed Kanban a good method to build on further? It's because of the "visualize" part. That's about the only thing that is unquestionable about the Kanban method: visualization. Nothing else supports the pragmatic, use-your-guts thinking better than visualizing. Indeed, when things are brought from heads to paper (or to screens), that's a huge aide. Pragmatic stakeholders need more ways to look at what happens with their projects and processes, than with static Kanban cards that signify work items.
Now, as I've identified this method, for free-thinkers who want unlimited help and unlimited freedom with their unique ways of thinking, let's see which digital tools might support this. Most of the Kanban tools are limiting. They lack versatile visualizations. Here's a write-up about one such pretty decent Kanban tool that, however, fails to deliver many views and many perspectives. Quite predictable, I found out that so far only Targetprocess 3, our visual management software, supports the unlimited thinking and free-from-the-leash no-nonsense work — and the Multiban method — as it brings to the table unlimited 2D views for any dataset. No strings attached, the tool also allows to exercise agile, Scrum, Kanban and other SUPER ABC things. But the most important part about Targetprocess 3 is that it supports your own unique way of thinking and decision-making, be it on micro-level with bug fixing, or work items management, or on macro-level with managing portfolios of projects, or with roadmaps, in ERP or wherever.
I'm probably trying to squeeze too many things in one article. Each of the aspects I've touched upon deserves an article by itself. I'm certain that what this world lacks most is insightful out-of-the-box thinking. People are stuck in prescribed patterns on many levels in their lives, their work in software development, or organization/product/project management being one of them. I want to tackle this, and that's why I will persistently champion the smart pragmatism and the Multiban method in my writings.
If you want to learn more about how Multiban stands out as a method and as a technique for visual management, check the related articles.
Kanban as Multiban
Stuck with Kanban? Consider Multiban
Our Evolution of Visual Process Management
What's Wrong With My Kanban Board?
... no matter if it's agile, Scrum, Kanban, SAFe, lean, XP or some mix of these methodologies.
Project managers want to track progress in any software development project, small or large. Sometimes they want to track progress not only in one, but in many projects at a time, and they want to be able to do this fast and conveniently. A timeline is a a visual management tool that helps accomplish this. Let's take a closer look in which way.
Regardless of the software development methodology used, projects are meant to be completed. Always. However, at times project managers feel tied to by-the-book canons of Kanban (which is viewed by many as the best visual management system there is, but allows no time-boxing), or of Scrum (which has time-boxed iterations and releases but falls short with the visual part). What if a project manager wants to get the best both of Kanban, as a visual board, and of Scrum? Obviously, if projects have deadlines, one can not live by the classical pull and flow formula of Kanban only.
For progress tracking, Scrum allows only one visual report, called the burn down chart. When we want to keep an eye only on one project, such a report would probably be enough:
However, if many projects need a watchful eye of this one person, squeezing many burn down charts on one screen will not make the job any easier. Imagine how hard it would be to make sense of those charts arranged in a grid-like fashion. A project manager will likely want to see how projects correlate with each other, as it might be that the timing in one project affects the other projects. In this case, it would be sensible to drift away from the prescribed tool set of Scrum, and venture into the unknown land, fearlessly mixing sense of time (Scrum) with a neat visual representation (Kanban). That's how this stylized mix looks as a timeline view for 2 projects (click to enlarge):
Work items in several projects on a timeline in Targetprocess 3
Such a visualization will fit a dozen projects into one screen, showing a project manager how all of them correlate with each other. This timeline has something more in store, than merely registering projects' health in terms of time. Unlike in the burn down chart, one will be able to zoom in on any work item in any project and see what's going on. This timeline bears a certain resemblance to Kanban board, because bugs, user stories and features are presented as cards stretched over time. At the same time, as in Scrum, the forecast will update depending on velocity (if one needs it done that way), and the timeline will show the latest status. If a project manager is in charge of several teams, that do several projects, this timeline will show when one can expect these projects to be completed:
A teams/projects timeline in Targetprocess3
A yet another snapshot of tracking progress with timeline. Here we have Features and User Stories (as in Scrum):
User Stories inside Features on a timeline in Targetprocess 3
When someone pledges allegiance to Scrum, timelines offer a way to track progress with many iterations. Same for many releases, as opposed to clicking through single release and iteration plans one by one.
Tracking progress/status for several iterations on a timeline in Targetprocess 3
As we can see, it pays off when we forget about practices that seem to be rigidly prescribed by a methodology. A methodology is nothing, unless it works for our purposes, and helps us do the work better and faster. These timelines can not be, scholastically, classified as belonging solely to Scrum as a method, or to Kanban. While classical Scrum only offers burn down charts for progress tracking, this is not enough when people work with many projects and want to keep their hand on the pulse of all of them. Classical Kanban, in its turn, allows no time tracking as a methodology (and as a visual board). I'm not even sure if what they call "Scrumban" would accommodate this representation with timelines. Frankly, I don't care how it's called. I only care if it works for project managers or product owners, or any other folks in charge of projects, and helps them do their work well. And I wish that people were more of a freethinkers, unpinning themselves from the methodology labels.
Care to take a look where one can afford being a freethinker and still work as a project manager? With no strings attached to Kanban, or Scrum, sticking only to common sense and convenience of work? It's here.
How Visualize: Board, List or Timeline?