“Research is formalized curiosity. It is poking and prying with a purpose.”
-Zora Neale Hurston
So as I thought about my earlier post on the idea of an Agile MBA, I realized that there is a whole lot that goes into putting together something like that. So before heading down that path, a guy might be well advised to check and see if there is any real interest in the idea before wasting a lot of energy on pursuing it further. So with that thought in mind, I created openagilemba.com.
The idea is simple, taken from the lean startup world. If you have an idea, put it out there and test whether or not there is a market for it. So I’m doing exactly that. Go check it out. I named it the “Open” Agile MBA because I’m not trying to sell anyone anything. What I have in mind is more of an open source MBA model. If we can assemble the resources, then anyone can use them. That’s kind of an exciting idea. It’s not new, there’s a NoPay MBA out there that is really cool and does something similar for a standard MBA.
So I’m starting with small, agile steps. Simply put up a web page and ask people if they are interested. If I get a few responses (feedback!), then I pursue it further, if it’s just crickets, then perhaps I tweak the idea and try again. I can’t wait to find out!
Filed under: Agile, Lean, MBA Tagged: AgileMBA, Lean Startup, Open Source, Testing
Once upon a time, there was a company that said it was customer focused. They used Agile methods to incrementally build software. At the end of an iteration, each team within the company would conduct a demo session. The feedback from the demonstrations would be used to adapt the product toward what was deemed as customer value. When the demo was investigated, it was learned that there were no actual customers or end-users in the demo. The question that may then be posed is if there are no customers in the demos, then what are the teams adapting too?
What appears to be a challenge to some companies who say they are customer-focused or Agile, is how to successfully construct a functional demo. The short answer is that customers or at least the end-users must attend the demo. Of course this is more easily said than done. The long answer is to establish a the Agile Customer Feedback Vision. This vision is a strategy for identifying the right customers to attend, applying personas that represent the various customer groups, establishing feedback sessions throughout the work, and then motivating the customers to attend the feedback sessions.
In the meantime, how do you highlight the problem of the missing customers? Certainly those in the company understand that gaining customer feedback is important to the success of a product. Even when providing companies with the mechanics of a customer feedback vision, customers are still found missing from the demos. Why is that? Maybe it's important to illustrate the obvious, that customers are indeed missing from the demos. One way to illustrate the obvious to companies and their teams is by applying the Empty Customer Chairs technique. The Empty Customer Chairs is a visual way to highlight the absence of customers at a demo of the product. The technique is applied by having 3 chairs that represent the customer at a demonstration. If customers attend the demo, they fill the chairs. If no customers attend the demo, then the chairs remain obviously empty. If the demo is held virtually, then 3 virtual screens are designated to customers. If no customers attend, then those 3 screens remain empty.
It would be hoped that a company or team realizes the benefit of customer participation. Until such time, this technique can help you illustrates the obvious lack of customer participation that may have the intent to motivate the filling of those seats. At the end of the day, it is all about delivering customer value and this is a technique that can help you highlight the importance of this value through the absence of the customer.
When I introduce people to retrospectives I often am asked what topics should be covered and not covered as part of this. When I have asked this question of other people, I hear answers like “Everything should be open for discussion” or “No topic is ever taboo.”
Although I agree with the sentiment, I strongly disagree with the statements.Photo from coltera’s flickr stream under the Creative Commons licence
Yes, being able to discuss most topics openly as a team, particularly where there are different views is a sign of a healthy, collaborative team. Even then, I still believe there are two topics that teams should watch out for because I feel they do more harm than good.1. Interpersonal conflict
Imagine yourself working with a team where two people suddenly start shouting at each other. You hear voices continue to escalate, maybe even watching someone storm off. An uncomfortable silence descends in the open team space as no one is quite sure how to react. Is this something you discuss as a team in the next retrospective?
Perhaps if the issue involves the entire team. When it involves two people where tension escalated too quickly over a single topic, it is more likely you need mediation and a facilitated conversation. A person wearing a leadership role (e.g. Project Manager, Line Manager, or Tech Lead) may be an ideal person with context to do that, but it may also be better to find a mediator who can get to each person’s interests and to find a way to both move forward and to start healing the relationship.
Although it will be impossible to ignore the topic in a retrospective, the focus should be on team expectations about behaviour, or identify ways the team can support each other better. It is unlikely you will solve, as a group, the conflict between the two people without making each of them very uncomfortable and unsafe.behavioural issues for a single person
Just as you wouldn’t isolate two people and make the entire retrospective about them, teams must not “gang up” on a single person unless they feel safe to discuss the topic. If the entire team complains about what a single person is doing, the person is likely to feel targeted, isolated and potentially humiliated in front of their peers.
It may still be important to highlight issues impacting the entire team, but be careful that a retrospective does not become a witchhunt.
Where repeated, consistent behaviour needs to be addressed, a better solution is targeted one-to-one feedback.Conclusion
Retrospectives are important practices for agile teams, but it is not a tool that will solve all problems. Retrospectives work well with other tools that offer better, more focused conversations for smaller groups such as mediation and one-to-one feedback.
What topics do you think should be avoided in retrospectives? Please leave a comment with your thoughts.
A lot of people talk about code optimization, and most of the time they mean memory and performance. But there are a lot of aspects of code that can and should be optimized – including the ability to easily read and understand the code.
In this quick video, I’ll talk about why I think code should be optimized for readability, first, and not for writing or editing or performance or whatever else. I’ll also share when I think it is important to optimize for other aspects, as well.
The best architectures, requirements and designs emerge from self-organizing teams.
The quality of our software systems depends on refactoring. In fact, I believe that the only way that an organization can avoid refactoring is by going out of business. Maybe I should explain that.Refactor or Die
Every software system that we build is inside a dynamic environment. The organization(s) using the software are all in a state of constant change. The people using the software are also constantly changing. Due to this constant change, every software system needs to be adapted to the environment in which it is used. Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle. Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security. But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.
What happens when the business does not recognize those invisible qualities? I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex. Some people refer to this as legacy code or technical debt.
The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about. It is pretty easy to see how this works – for someone who has a technical background. But for those without a technical background it can be hard to understand. Here is a little analogy to help out.
Imagine that you set up a system for giving allowance to your kids. In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature. After a few weeks of doing this, you realize that it would be helpful to have the date on the form. You do this so that you can enter their allowance payments in your personal bookkeeping records. Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment. Then your kids want extra allowance for a special outing. So you add some things on the form to allow them to make these special requests. Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes. So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes. Your form is getting quite complex by this point. Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances. Every new situation adds complexity to the form. The form expands over multiple pages. Filling out the form weekly starts to take significant time for each child and for you to review them. You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet. You decide you need your own checklist to make sure that the forms are being filled out correctly. A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version. It takes three days, and there is lots of guess-work. Your allowance tracking forms have become a bureaucratic nightmare.
The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step. The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.
For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:
Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features. If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.
I used the word “decision” in that last sentence. What are the other options in that decision? Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while. Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details). At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system. Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.
In his articles, Kane Mar describes this like so:
It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.
In other words, refactor or die.Refactoring and Business
In the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring? How do we “govern” it? How do we make good decisions about refactoring?
There are a few principles that are important in helping to answer these questions. All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.Refactoring Principle One: Keep It Small
Refactoring is safest and cheapest when it is done in many small increments rather than in large batches. The worst extreme is the complete system re-write refactoring. The best refactoring activities take seconds or minutes to execute. Small refactorings create a constant modest “overhead” in the work of the team. This overhead then becomes a natural part of the pace of the team.
Not all refactoring moves can be kept so small. For example, upgrading a component or module from a third party might show that your system has many dependencies on that module. In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously. This allows your system to be partially refactored. In other words, to break a large refactoring into many small refactorings. This, in turn, may force you to refactor your system to be more modular in its dependencies.
Another common problem with keeping refactorings small is the re-write problem. Your own system may have a major component that needs to be re-written. Again, finding creative technical means to allow for incremental refactoring of the component is crucial. This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously. One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.Refactoring Principle Two: Business Catalysts
When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it. Instead, the technical team needs to use business requests as catalysts for refactoring. If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature. In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.
Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date. This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code. So, instead, we need to allow the technical team to refactor when they detect duplication. Duplication of code, data or structure in the system. A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result. But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution. Later, the business makes another request that also implies the same large refactoring. Now is the time to seriously consider it. It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies. However, the technical team must also be willing to push back to the business under the right circumstances.Refactoring Principle Three: Team Cohesion
Teamwork in Agile requires high levels of communication and collaboration. In refactoring work, teamwork applies just as much as in any other activity. Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring. But that is just the first level of team cohesion around refactoring.
The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring. Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring. This last idea is best expressed by the concept of refactoring to patterns.
The highest level of team cohesion in refactoring comes from collective code ownership and trust. Usually, this is built from practices such as pair programming or mob programming. These practices create deep levels of shared understanding among team members. This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support. It also impacts research and learning processes so that teams can do experiments and try alternatives quickly. All of which leads to the ability to do refactoring, large and small, quickly and without fear.Refactoring Principle Four: Transparency
In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring. This can be difficult at first. Another analogy helps to see the value of this. A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc. In fact, all of those things contribute to the cost of surgery. A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them. Likewise, software professionals need to be open about the costs of refactoring. This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest. Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.
The challenge for business stakeholders is to accept the costs. Respecting the team and trusting their decisions can sometimes be very hard. Teams sometimes make mistakes too, which complicates trust-building. The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring. Ideally, it is continuous, small, and low-level. But once in a while, a team will have to do a large refactoring. How do you know if the cost is legitimate? Unfortunately, as a non-technical stakeholder, you can’t know with certainty. However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.
If the refactoring is small, it is more likely to be legitimate.
If the refactoring is in response to a business catalyst, it is more likely to be legitimate.
If the refactoring is reflective of team cohesion, it is more likely to be legitimate.
And, of course, if the refactoring is made transparent, it is more likely to be legitimate.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
After AnnuityNet was acquired in 2006, David became drawn into the world of corporate innovation. He’s helped some of the most famous corporations in the world launch new products through rapid market validation. Beyond launching new products in the market, David helps corporations design a repeatable process to fund disruptive innovation. Prior to founding PRECOIL, David pioneered innovation services at Neo and BigVisible. Learn more at Precoil.
Bad news, the lifespan of corporations is shorter than ever. Features are added to core products and yet no one cares. High Retention + Low Satisfaction products are experiencing year-over-year decline and are now easily overtaken by startups who can scale globally like we’ve never seen before. The good news is that many of the methods used by startups can also be adapted to your corporation, without destroying your brand in the process.
By now you should be familiar with the Build Measure Learn cycle from The Lean Startup book. Chance are, you’re trying to innovate more so that your company isn’t one of those who succumbs to the upstarts — I mean startup. However, one of the biggest misunderstandings today in big corporations trying to innovate more like startups is that they start with Build. One of the key learnings in being a successful and effective innovator is to shift your thinking away from starting with build, to starting with Learn, then progressing to Measure and finally Build.
Let’s look at the implications of “starting with Learn”.Step 1. What do you need to learn?
Before jumping to Build, start by asking “What do I need to learn about the problem or customer?” It sounds nuanced, but starting with Learn changes the entire dynamic of your product design process. You are crafting a hypothesis instead of jumping to building features or a prototype.Step 2. What do you need to measure to learn?
Once you’ve defined what you want to learn, the next step is to identify what you need in order to learn. If you have data, this may entail bringing in a data scientist to make sense of what you have. There is a huge difference between looking at data and looking for data.Step 3. What do you need to build to measure to learn?
If you don’t have the data needed to measure, then define what you need to build to generate that data. This is what distinguishes a Minimum Viable Product (MVP) from a Prototype. An MVP is heavily instrumented with analytics and optimized for learning, not scaling.Applying Build-Measure-Learn to the Enterprise
Now that you are starting with Learn, have worked your way backwards through the build-measure-learn loop and are ready to move forward, there are other challenges you’ll face in a B2B enterprise setting that aren’t as common in startups. I like to frame these as either UX (user experience) Level and OS (operating system level) Level of your organization.
The UX Level of your organization is where you begin to socialize the ideas of working this way. It is quite visible and involves interactions with other coworkers. For example, things like having demos, daily standups, retrospectives and using sticky notes are at the UX Level. It is relatively easy to start using these techniques while trying to move through the build-measure-learn loop.
The OS Level of your organization is much deeper and has been hardened over years, perhaps decades. These are the basic functions of your organization that go beyond the UX Level of adopting Lean Startup or even Agile techniques. While you can easily make progress having standups and using sticky notes, none of these address things like ownership, performance reviews, accountability and incremental funding. If any of your retrospectives touch on deeper, OS-Level problems, they typically go unresolved and ultimately disempower your team.
So while you cannot change the OS Level right away, you can take some steps to start generating awareness and having a conversation about the fact that these items will ultimately cause you to fail from completing the loop.Start with Incremental Funding
Whether you call it incremental funding or not, I highly recommend setting the right funding and runway expectations as you use Lean Startup. Instead of having a team of 20 build for six months, try having a team of five that rapidly iterates for three months. Have a conversation with leadership to schedule a pivot/persevere/kill decision meeting three months out on the calendar. In that meeting, you’ll review all of the experiments you’ve run and what you have learned and then present a recommendation on how to proceed.
It is difficult for stakeholders to resist this approach, because the math make so much more sense compared to how you probably operate today. It also gives the ability to pivot and adjust the product direction as needed, much sooner than the alternative.
For more on Lean Startup, incremental funding and other advanced concepts like Design Charrettes, Assumptions Mapping, Innovation Accounting and more, join me at SolutionsIQ in Redmond on April 19 for my “Lean Startup in the Enterprise” Workshop.Register Now
The post Starting with Learn: Lean Startup in the Enterprise appeared first on SolutionsIQ.
Salut! Hallo! ¡Hola! Olá! Hello! Всем привет!
We’re excited to announce that Targetprocess will now include localization for our most requested languages. You can now use Targetprocess in English, French, German, Spanish, Portuguese (the Brazilian variety), and Russian.
This feature has taken some time to implement because we had to go through our entire source code to remove hard-coded strings and substitute them with a reference to the files containing translations. This important one-time activity is complete, so future languages will be easy to add.
Translations for the 5 new languages have been provided by native speakers via Alconost.com. We use Transifex, a localization platform, to implement the translated text. We want to thank these two great services for making the process a breeze.
To implement localization for your Targetprocess account:
Go to “My Profile” (by clicking on your portrait in the upper right hand corner), then select the “Account Settings” tab and adjust your language accordingly. Click “Update Settings” to finalize the change.
Go to your profile….
....and select your preferred language in Account Settings
Don’t forget to click “Update Settings” to apply the translation!
Some important things to keep in mind:
- Localization is applied per user, so you can now have an international team that uses Targetprocess in several languages
- We still only provide product support in English and Russian
- New features will be localized as they are implemented, but the translation may come slightly later than the feature
- We implement languages according to user demand. If immediate implementation of a certain language is critical for your team but not widely requested, then there may be a translation fee
- To request a new language, contact your product specialist or our sales team
- New translations will take approximately 3-4 weeks to implement
A list of items that will not be translated with localization:
- Our user guide
- The administrator’s user interface
- Custom fields and custom terminology (although we provide translation for default terms)
- The Solution Gallery
- Targetprocess videos
- Email templates (things like email notifications for tasks)
- Date and time formats
If you have any questions or comments about localization, please drop us a line! We eagerly welcome your feedback on any mistakes, typos, incorrect translations, or suggestions for better translations. You can reach us at L10N@targetprocess.com.
For feedback on specific items, please specify the existing translation, your suggestion, the place where this string appears, and (if possible) a screenshot of the message. This will help us to correct the error faster. Please note that the messages may be complex (dynamically composed of several parts) so your correction may not always be applicable.
Have a good day everyone! Bonne journée! ¡Tenga un buen día! Xорошего дня! Tenha um bom dia! Schönen tag noch!
Notitia linguarum est prima porta sapientiae.
Knowledge of languages is the doorway to wisdom.
- Roger Bacon
Targetprocess v.3.8.3: Sorting Order for Comments, Term for Request, New Languages, Workflow Management for Functional Teams
You can now specify the order in which you would like to see comments on cards. From the card description, choose to display either the oldest or newest comments on top. It's a per-user setting, so everyone will be able to set up their own preferred order for following comments.
From now on, it is possible to rename 'Request' with our Terms editor in the same way as other entities. For example, you can rename 'Request' to 'Requirement' and collect requirements that come from your clients throughout the project.
Targetprocess can now be used in 6 different languages: English, German, French, Spanish, Portuguese (the Brazilian variety) and Russian. Translations in all these languages have been completed. English still remains the main language of the system, and the administrator's user interface is not supposed to be translated for now. Every user can switch to one of the new languages via My profile - Account Settings. Read more
We have finished the Beta testing of our new feature and are proud to announce that Workflow Management for Functional Teams is now publicly available. The new functionality will be useful for companies who have teams working sequentially. Accounting, Marketing, Designers and Development are examples of such teams; they are often called functional teams. From now on, several teams can work on the same item – e.g. a feature or a user story – one after another. So, the final state of an item in the workflow of one team is its first state in the workflow for another team. Read more
- Filtering by entity-specific fields when several card types are selected at the same time
- Fixed export failure when last commented user name is not specified
- Fixed saved context override by global context
- Fixed failure with renaming tags if they have a long name
- Fixed issues with import for Bugzilla plugin
- Fixed problem with allowing prioritization in lists with the configuration when prioritization should not be allowed
- Fixed sorting in lists for some units when more than one card type is selected on setup
- Fixed problem with filtering projects by anticipated end date
- Fixed problem with the possibility to create allocations beyond the project end date
- Fixed incorrect handling of unsupported expressions in visual filters
- Fixed filtering users by custom fields using api/v1
Each year the VersionOne team nominates employees for the annual Spirit of VersionOne award to recognize an individual who best represents the core values of VersionOne. This year we are sincerely honored to announce that Mark Schultz is the Spirit of VersionOne award winner.
Based on nominations from fellow employees, Mark exemplifies the culture and spirit of VersionOne. He is respectful, honest, authentic, and truly cares for the success of his team, colleagues, and customers. Many of the nominations also referenced Mark as the ultimate servant leader, who is constantly looking for ways to use his experience to help others succeed. The only attribute that exceeds his work ethic is his passion for the success of the company and its employees.
Since he first joined the company more than five years ago, he has consistently gone above and beyond to be available to others whenever needed. His positive attitude is extremely infectious. And while years of success have provided Mark with a wealth of experience to share, he remains incredibly humble and willing to learn from the experiences of others.
In a world of many managers, Mark is a true leader that inspires many on a daily basis. Trust, humility, and integrity are some of the qualities that great leaders possess and all of which you will find in Mark. It is rare to find one individual who has this combination of personal and professional integrity at such a high level. Thank you, Mark for your unselfish commitment to VersionOne!
Anyone monitoring the voluminous flow of words advising CIOs how to “align with the business”, “deliver more strategic value”, and “implement a modern digital strategy” has witnessed the debate about “bimodal IT”. Gartner introduced the concept in 2014, recommending that CIOs run two distinct modes of project execution in their corporate IT shops. Mode 1 is deliberately slow, “traditional and sequential, emphasizing safety and accuracy”. Mode 2 is fast and responsive, designed to incorporate customer voice, learn and iterate towards better products quickly. Predictably, several large traditional consultancies immediately offered CIOs their off-the-shelf bimodal or “digital” implementation services, promising quick and easy ROI by using value-driven, customer-centric, Agile approaches on a few projects, while conveniently leaving slow legacy structures and processes unchanged for most of the organization.
We can all agree that the need for dramatic improvements in user focus, accelerated time to market, and improved responsiveness is common in Fortune 500 IT organizations. Market-dominant firms tend to become inwardly focused and bureaucratic, less innovative, slow and risk averse. Disengaged from customer voice, IT ships poor products full of unused features. Knowledge workers disengage and become order takers, their work lacking purpose and their mission increasingly obscure. Ideas for new products or business model innovation is stifled in an effort to avoid cannibalizing cash cows. Organizational performance suffers, revenue growth slows, and emergent threats steal market share.
Bimodal IT, Gartner puts forth, would help address some of these problems, but does it really?Is Bimodal IT a Breakthrough Insight or a Convenient Half-Truth?
By promising to quickly deliver the benefits of a digital innovation center without having to face the challenge of addressing IT’s legacy organization and processes, bimodal IT almost seems too good to be true. For technology organizations considering investing in a significant performance improvement initiative, I have prepared a comparison of the relative merits of the siloed bimodal approach typically espoused by consultants with a more holistic enterprise-wide Lean/Agile transformation approach, in which bimodal IT is a transitional state in the journey to becoming a high-performance organization.
First let’s consider the benefits of Bimodal IT. Bimodal IT is attractive to IT organizations facing problems with speed and responsiveness, and the approach can deliver modest benefits, at least for the Mode-2 portion of the portfolio. Those benefits include:
- Increased focus on incorporating customer/user feedback to deliver better products than IT organizations typically deliver
- Faster cycle times at all stages of the delivery lifecycle to speed time to market
- Improved efficiency by delivering more value per dollar invested
- Reduced risk and increased ROI by breaking large projects into smaller increments that deliver value early and often, and surface problems earlier with less sunk investment
- Enabling organizations to leverage modern technologies and focus more on innovation through rapid experimentation using validated learning, a “fail fast” mentality, and quickly pivoting in favor of better solutions — like a Lean startup would
- Enhanced acquisition and retention of top talent — engage employees’ passions by delivering compelling solutions that thrill users and drive markets — in other words, being able to develop software like a real Silicon Valley tech company!
The appeal of bimodal IT stems from a problem almost as old as IT itself: older technology systems in “support” or “sustainment” mode typically contain high levels of technical debt, making changes slow, risky, and unpredictable. CIOs know their organizations and legacy applications are devilishly difficult to accelerate and improve, but pressure from line-of-business leaders to support innovation and deliver digital solutions more rapidly is increasing daily. Line-of-business increasingly bypasses IT by outsourcing development directly or building shadow-IT organizations. This threatens corporate IT’s influence and resources.
Unfortunately, the simplistic implementation of creating a new mode 2 silo without organizational integration fails to deliver significant benefits and often produces negative ROI from the collateral damage resulting from significant tension and conflict among the people, processes, and technologies of the larger organization. The problem isn’t simple, and the magnitude of improvement required is large, so the quick, simple, and cheap solutions that consultants propose should be scrutinized carefully.
Bimodal (or better, multi-modal) done right acknowledges that, in an optimized high-performance technology organization, there are a range of project types, technologies, and people that should be supported with appropriate process frameworks focused on minimizing waste, managing risk, and delivering maximum value as early as practical. Moreover, process tailoring must support the effective interoperation and collaboration of the people, processes, and technologies throughout the organization.Don’t Let Bimodal IT Become a Leadership Cop-Out
Leaders in any industry leveraging technology assets must grasp Lean thinking and embrace modern leadership principles to gain maximum performance from knowledge workers. I say this not for altruistic reasons, but as an avowed capitalist. Modern leadership maximizes the performance of firms in our competitive modern economy. The path to achieving process maturity and organizational performance starts with a commitment to continuous improvement at the leadership level, paired with an effective organizational learning and change management program sponsored by committed leaders.
“The Toyota Way” is one of the first books to describe the revolutionary new product development and manufacturing processes developed and used at Toyota. In it the author, Jeffrey Liker, says:
“When I first began learning about the Toyota Production System, I was enamoured by the power of one-piece flow, Kanban, and other Lean tools. But along the way, experienced leaders within Toyota kept telling me that these tools and techniques were not the key. The power behind TPS is a company’s management commitment to continuously invest in its people and promote a culture of continuous improvement. After studying for almost 20 years…..this is finally sinking in.”
Given this context, please consider: Is bimodal IT really a strategic path to renewed competitiveness and IT value delivery? If not, what is the optimal path to achieve transformative performance improvements? Are we preserving outmoded legacy processes and behaviors that undermine our business goals out of fear, ignorance, or complacency? Even if transitional bimodal IT is a step along the journey, it surely cannot fully address the strategic need to optimize technology delivery to seize market share, exploit new market segments, and accelerate revenue growth in new products and services.
This blog is an introduction to a larger and more comprehensive treatment of the pros and cons of implementing bimodal IT in a forthcoming white paper. In it, I will provide an overview of a more powerful, integrated, and holistic approach: a full-scale Agile transformation that can address the entire value stream between ideation and delivered customer value.
As Liker discovered in his journey mastering “The Toyota Way”, the long-term success of an organization doesn’t emerge from tactical techniques and quick fixes; it depends on a culture of continuous improvement fostered by engaged and enlightened leaders.Like this? You’ll love Agile Eats
Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!