Esko Hannula’s Three Skills of Advantage book launch
Qentinel CEO, Esko Hannula launched his work of non-fiction, Three Skills of Advantage to an appreciative audience at Helsinki’s Finlandia Hall on February 16. The book received positive reviews from a panel of business leaders who went on to discuss some of its main theories.
Addressing the gathering, Hannula said that managers need to practice the skills of quality, agility and decision to succeed in an uncertain, complex and dynamic world.
“We live in an economy of speed, governed by systemic complexity and dynamism. Changes in the operating environment date even the best of plans and decisions. The detailed planning and centralized decision-making that we have been culturally and educationally programmed for, no longer work. Everything is uncertain,” Esko Hannula declared in the book.
Hannula has spent more than 25 years in leadership positions developing innovative products, solutions and technology. Three Skills of Advantage represents a compendium of what he has learned during his extensive career, primarily that it is impossible to control reality and that we must learn to manage uncertainty.
“We cannot control risk. We can only manage ourselves in relation to risk. Some years ago, I myself stopped talking about risk management completely. I started to talk about managing with uncertainty. As a concept, uncertainty is easier to accept and process than risk. Managing is also a more realistic mindset than controlling,” the writer pointed out.
Practice makes perfect
In the book, Hannula compares practicing the three skills of advantage to the approach a musician takes in preparing for a recital or performance. Behind every performance by a professional musician lies years of practice – compared to the average manager. Musicians spend time finessing their techniques to perfection and release all their creative energy in a unique musical experience. Finnish vocal talent and star of the British X-Factor talent search competition Saara Aalto is featured in the book, explaining her approach to excellence.
During the launch event, internationally renowned Finnish pianist Paavali Jumppanen delivered a compelling performance of three études by French composer Claude Debussy, each piece dedicated to one of the three skills of advantage. Jumppanen said that as a musician, the skill of inspiration is most important to him. See his interview on a video.
Panel ponders managing with uncertainty
A panel of forward-looking business leaders commended the book’s key insights and discussed the challenges facing autonomous organizations. Helsinki customer experience developer Sami Paju provided insights on how to maintain a common direction while avoiding chaos. Tarja Pääkkönen of the board-level networking firm Boardman described the role of inspiration and faith in developing strategy in an environment of uncertainty.
COO of the consumer finance company Euroloan Group Joachim von Shantz advocated for processes to manage risk. However, he noted that not all risk can be avoided. “If an unexpected risk appears out of left field, then we are already dealing with a problem. They [risks and problems] are dealt with separately,” he added.
Minna Nissinen, a senior vice president of the investment and corporate services group Salomaa, picked up Hannula’s thesis that an environment of uncertainty requires the skills of both bold pioneers and meticulous planners. “This perfectly ties together and crystallizes the spirit of our times, the need for active assumptions for management, a decision-makers most important tools, responsibility for decisions and their consequences,” she declared.
Three Skills of Advantage will soon be available in Finnish online and as an e-book from Amazon. An English version will be published in April.
6 SAFe® practices that make sense also for S sized teams
SAFe – Scaled Agile Framework® – was created to tackle the challenges of M – XXL sized projects. Such projects consist of several agile teams having in total from ~50-100 up to hundreds or even thousands of practitioners. How about S sized projects with just one or a few teams, is there anything in SAFe for them or is Scrum just enough? If the team is a relatively independent pure software team and the project is short, Scrum (or Kanban) would be the way to go. However, an S sized team can benefit from selected SAFe practices at least under the following circumstances:
- Strategic software product with a long lifespan. The longer the lifespan of the SW product, the more important it is to link SW development explicitly to the strategy of the enterprise. Scrum doesn’t provide much support for linking SW development to the longer-than-sprint time span of strategic goals.
- Expectation to scale up from S to M size. If a startup (a new business or an internal startup) has a strong projection for growth, it makes sense to prepare for it up front and use approaches that scale up when needed. Scaling up can be terribly slow and challenging unless the scaling capabilities have been built from the ground up.
- Dependencies with multiple (non-SW development) teams. It’s not rare that a company has a relatively small SW team delivering SW for multiple other teams for integration. The SW teams in hardware and services companies with moderate SW assets but a decent portfolio of products face this situation. Software companies whose product is heavily tailored for each customer through delivery projects have this multi-project challenge, too. All the dependent teams need to agree on priorities and plan together.
- Necessity to invest in long term capabilities such as DevOps. Focusing on delivering the next set of user stories, sprint by sprint, easily sets aside longer term investments in team’s own capabilities. It’s easy to agree that DevOps capabilities are needed but becoming a true DevOps team requires efforts that need to be planned and executed like a project. Changing the development technologies or modernizing the software architecture are other examples of long term capability investments that are true projects on their own right.
There are ways to handle all these four cases with pure Scrum but my own experience suggests that it’s better to cherry-pick the following 6 practices of SAFe to deal with them.
Reproduced with annotations added by Juha-Markus with permission from © 2011-2017 Scaled Agile, Inc. All rights reserved. Original Big Picture graphic found at scaledagileframework.com. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile Inc
1. Strategic Themes
All companies, big or small, need a strategy to be successful. It is crucial to understand how the products of the company create value to customers in terms of impact to processes/doing and the concrete benefits customers gain. Product quality and the user experience are equally important for the long term success. In addition to product strategy, a software development team needs to have an idea how to continuously improve its SW engineering capabilities to improve its productivity and competitiveness.
While SAFe does not offer explicit tools to identify the value creation logic nor for building the strategy, it does have Strategic Themes that are the business objectives that connect team’s portfolio to the strategy of the enterprise.
I have used Strategic Themes as explicit planning domains in iteration planning (Program Increment Planning as well as in Sprint Planning) to ensure that the team works on strategically relevant items. Some tools such as Visual Studio Team Services (VSTS, the one my current team uses) allow tagging the work items with theme keywords which further helps analyzing the backlog items vs. strategy. If a strategy exists, the step to identify the strategic themes requires only little effort so I think it’s worth it.
2. Program Epics
Scrum teams typically interpret epics just as too big user stories that don’t fit in one sprint. SAFe contains a rich hierarchy of epics to ensure sufficient scaling: Portfolio (business) Epics and Enabler Epics, Value Stream Epics, and Program Epics. Portfolio and Value Stream Epics are not relevant for small scale development but Program Epics are.
SAFe defines Program Epics as “initiatives significant enough to require analysis using a lightweight business case and financial approval before implementation”. I assume that the requirement to prepare a business case for something is not the very point here; the point is to ensure that an Epic is something that creates desired significant value and is doable. Thus, when a team works on a (Program) Epic linked to a Strategic Theme, team’s effort contributes to something valuable that is aligned with the strategy of the company.
Epics are useful for an S sized team as they describe the key initiatives of a team that are ongoing or being proposed by its stakeholders or invented by the team itself. A SW team should have also some Enabler Epics in its portfolio in addition to Business Epics to e.g. improve its architecture or DevOps capabilities.
As “significant enough initiatives” tend to require significant investments (relative to resources), so a light weight business case is worth doing for each Epic before jumping to implementation or rejection. This is particularly useful when the team has several stakeholders and their initiatives need to be prioritized and matched to team’s resources in order to make the prioritization discussion meaningful.
3. Program Kanban
SAFe contains scalable Kanban systems to manage portfolios of initiatives at enterprise, value stream and program levels. The program level is sufficient for an S sized team and it is particularly useful in the case that the team has several stakeholders offering their own Epic proposals for implementation.
Program Kanban of SAFe provides a simple and transparent process to deal with the proposals for initiatives. It is used for capturing, analyzing, approving and tracking Epics. Epics that end up being done go through the Funnel, Review, Analysis, Portfolio Backlog, Implementation and finally Done states. For an S sized team the process to study the Epics can be extremely lightweight but these logical steps should be present anyway when the Product Owner thinks of the next initiative(s) and how the team can create most value. Managing the key initiatives as Epics on Program Kanban requires only moderate effort but gives good transparency to team’ priorities at portfolio level – also to the members of the team.
Feature is not really a part of the core definition of Scrum. There are just user stories. The big user stories are labeled as epics and a related bunch of user stories as themes.
What makes the Features particularly useful is that they are sized to fit in one Program Increment. That makes Features concrete deliverables and facilitates clear communication with stakeholders.
5. PI Planning
Scrum contains just the sprint cycle of typically 1-3 weeks (2 weeks being probably the most popular) as the planning and execution iteration. More often than not, Scrum teams provide true visibility to their plan for just the next sprint plus the backlog that hints at the order in which the user stories become possibly implemented. Different variations of PowerPoint and Excel roadmaps are used to address the need for longer-than-the-next-sprint visibility. Backlog tools typically allow planning the stories for future sprints and some provide forecasts based on team’s velocity and the ranks of backlog items.
Program increment (PI) in SAFe is “a cadence-based interval of building and validating a full system increment, demonstrating value and getting fast feedback”. The duration of one Program Increment is typically 8 – 12 weeks so 4 – 6 sprints (in SAFe terms ‘iterations’) of 2 weeks. The last sprint of the Program Increment is Planning and Innovation Iteration which will be discussed as the sixth practice below.
Just like there is Sprint Planning in Scrum, SAFe provides a planning practice for these super-sized iterations: PI Planning. I have conducted PI Planning workshops of SAFe more or less by the book also for S sized projects. The planning horizon of 8 – 12 weeks is short enough for accurate planning and long enough for the team to achieve something really valuable, a set of potentially shippable Features. I think PI Planning workshop is good use of time for all: the team gets an update of the ‘bigger picture’ and priorities and prepares the planning in an agile way. The stakeholders can contribute to the planning directly and get an overview of all work items that the team is engaged with. For an S sized team, the PI Planning workshop can be condensed into one (long) day so the investment of time is reasonable with regards to the benefits.
6. Innovation and Planning Iteration
Thomas Edison described his innovation approach as “one per cent inspiration and ninety-nine per cent perspiration”, so innovations require time and hard work, not just creative mind. Especially in ‘never ending’, continuous product development there is a risk that a team just executes sprint after sprint without taking a break and becomes exhausted. Sprints tend to be hectic and for an S sized team it is probably even harder to find time to work on some more risky, seemingly lower priority yet innovative ideas.
SAFe doesn’t have any silver-bullet solution to magically release lots of time for developers to innovate like Edison but its Innovation and Planning Iteration at the end of each Program Increment is something that teams should appreciate. This sprint should not have any new stories to be developed yet e.g. some system integration and testing activities, such as performance or security testing, may be done. Also the achievements of the Program Increment will be demonstrated to stakeholders and PI Planning for the next Program Increment conducted. But as the name suggests, during this sprint the team can also have a hackathon or otherwise work on innovations or e.g. infrastructure improvements. And last but definitely not least: the team can have a break from the hectic SW deliveries. Part of the break can be used for e.g. competence development.
Those were my half a dozen SAFe practices that I have found useful also for S sized teams. Strategic Themes shortlist the strategic priorities and help the team align with those. (Program) Epics define the value of key initiatives that the team needs to work on so that those can be meaningfully prioritized. (Program) Kanban shows the priorities and status of Epics for the stakeholders. Features elaborate Epics thus providing a common language for the team and its stakeholders and they are sized so that each of them fits in one Program Increment of 8-12 weeks. PI Planning happens at Program Increment cadence building a shared understanding of priorities and goals for the next 8-12 weeks. Innovation and Planning iteration at the end of each Program Increment gives the team a well-deserved break and allows the team to spend some time on innovating and developing its capabilities.
Juha-Markus Aalto leads product development of digital services at Qentinel. He has made an instrumental contribution to the lean and scalable requirements model of SAFe and implemented an XXL sized agile-lean transformation program when he worked at Nokia Corporation.
Press release – Finnish Customs invests in test automation development
Qentinel’s test automation solution to reduce manual test work for Customs
Finnish Customs has signed a two-year agreement with software quality assurance company Qentinel to deliver a test automation system. Qentinel’s test automation solution will help Customs reduce manual test work and ensure coverage through all stages of testing.
Finnish Customs is in the process of implementing several extensive software development projects. Successful conclusion of these projects also requires a completely new level of testing.
“Customs has long developed process automation and increased the level of automation of customs declarations handling, so investing in test automation is a natural extension. Investing in test automation has been a strategic decision and it is one of the key requirement for the success of our projects,” says Sanna Qvist, Finnish Customs’ Head of Testing.
“In addition to test automation we are also developing processes for test data creation and management. Customs’ IT systems are part of a large ecosystem, in which end-to-end testing requires comprehensive test data,” comments Miika Soininen, Country Manager for Qentinel Finland.
“The goal of Finnish Customs is to improve test coverage and to benefit from modern automated solutions for quality assurance of our IT systems,” notes Finnish Customs Development Manager Pirjo Heinäaro.
“Through a competitive bidding process we gained a partner that has accumulated extensive expertise from test automation projects in demanding environments to develop our testing,” Heinäaro comments about the partnership with Qentinel.
“The test automation work has begun in a good spirit of cooperation. Customs’ inhouse testers have been able to trial the automation and have described the Qentinel automation solution as easy to use, clear and even engaging,” adds Sanna Qvist.
“Test automation work has advanced from piloting of the automation solution to initial implementation. The project has progressed smoothly and we are already seeing evidence of its suitability for the Customs environment,” Heinäaro concludes.
Sanna Qvist, tel. 040 332 8885 / firstname.lastname@example.org
Miika Soininen, tel. 050 480 3712 / email@example.com
Finnish Customs is a member of the European Union customs system. Finnish Customs is an agency subject to the guidance of the Ministry of Finance and works in partnership with business and industry as well as domestic and foreign authorities. Finnish Customs employs about 2,200 people.