- Faster feedback
- Problems are localised
- Reduced risk
- Greater pressure and practice to reduce overhead
- See The Principles of Product Development Flow for more
Jeff Patton described this phenomena using the metaphor of a tree versus a bag of leaves:In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations. After all that work, after establishing all that shared understanding I feel like we pull all the leaves off the tree and load them into a leaf bag - then cut down the tree.
The "bag of leaves" approach to backlogs is a context-free prioritised list of work items, that is, the naive, and I'd argue typical for Agile novices, understanding of "backlogs". Although it nominally reflects a small batch approach, the "bag of leaves" discourages connection with underlying rationale and purpose, and therefore undermines autonomy.
Where I propose 5 attributes that indicate an effective approach to defining small batches in software developmentInstead, a more effective approach goes beyond work broken down into smaller pieces. A more effective approach...
- Highlights overall intention in the form of goals
- Highlights the logical relationship between goals and the work items that need to be done
- Visually represents goals, work items, and relationships in order to expose potential disagreement or misunderstanding
- Is designed to be done in a collaborative way
- Is iterative, that is, it does not require full completeness at the start
Note: This process should be iterative. It is only presented sequentially because that is easier to understand. It is not necessary, nor advised to try to fully complete every step in order. Instead, start with what you have and jump around and revisit steps as useful.
1. Identify GoalsWhat are you trying to accomplish?
This should be something observable and therefore measurable. For this reason, I like the term "impact" given that it implies something that is observable. However "goal" is more familiar to most people and I generally don't like introducing new jargon unnecessarily.
There may be more than one goal.
2. Identify Roles and ActivitiesWho has to engage in some Activity to achieve the Goals? OR What Activities need to be done by someone to achieve the Goals?
I generally prefer starting with Activities but in practice, this tends to be a very iterative process.
Note that Role is distinct from Person. The Person may play other Roles that don't have anything to do with your Goals but rather their own Goals. This typically means that you will need to add additional Goals that need to be supported.
3. Identify CapabilitiesWhat needs to exist in order for the Role to do an Activity?
A Capability may not need to be something that is built in software.
4. Identify Features and StoriesWhat needs to be done to create and/or enable a Capability?
Stories should be smaller pieces of work activity; Features are more to allow discussion at a higher level of granularity.
We are thrilled to announce the availability of Rally’s capacity planning capability — built for the program and portfolio level of enterprise scale Agile. With the new Capacity Planning page in the Rally platform, strategic planners can rapidly translate their business initiatives into realistic and adaptable action plans, without relying on disconnected, manually updated spreadsheets.
The new Portfolio > Capacity Planning page provides a staging environment for portfolio, product, and engineering leaders to collaborate ahead of release planning — without impacting the productivity of Agile teams that are busy delivering on the current quarter’s commitments.
Planners can play what-if scenarios to optimize the value of their near-term delivery plans, as well as create longer-term plans to inform hiring decisions. By creating multiple scenarios, business and technology leaders can review the realistic options of turning business initiatives into action before deciding on the final game plan.Less is More
It’s hard for businesses to accept the paradox that the less you do, the more you actually get done. Working on 10 different things at once is the recipe for delivering none of them.
The magic of the new Capacity Planning page is its sheer simplicity in visually identifying the right teams and the right scope — and right amount of scope — to bring into a quarterly release planning event. The page is instrumental in helping organizations build the predictability their business expects, and that predictability only comes when the right work and the right amount of work flows through coordinated, stable teams that have learned to work together to deliver quality, fast.
The Portfolio > Capacity Planning page
The new page is driven by four inputs:
Planning timebox: To adapt quickly to market and business changes, planners should have defined their continuous planning cadence. Using the planning timebox, they can select the time span for their capacity plans — from a single quarter or release for near-term planning, to multiple releases.
Prioritized feature backlog: Product managers should have validated a clear and ranked list of coarsely described features deemed most valuable to the business, tolerating incomplete data by delaying more detailed feature descriptions until what fits in a release is identified with the capacity planning cut line.
Rough estimates: Estimation teams — typically comprising team leads, architects, and other experts — should have provided roughly right estimates, tolerating incomplete data until release planning when those doing the work can provide more-refined estimates without impacting team productivity.
Teams: Engineering directors should have identified the teams involved in the capacity plan, following the team as the resource unit recommendation over individual roles and skill sets that provide a false sense of precision and accuracy.
The Rally Capacity Planning page delivers immediate benefits:
Limit WiP: Being able to see when capacity is reached ensures planners only schedule the work that matters most, and delivery teams can focus on delivering the plan faster.
Delivery predictability: By focusing on fewer features that matter most (as opposed to constantly context switching), teams can build delivery plans with predictable outcomes.
No time wasted detailing features for which teams don’t have capacity.
A solid, realistic plan to bring into release planning that optimizes the business investment in that event.
The Capacity Planning page has even more benefits that become obvious after you start using it. Our early adopters found the page instrumental in removing the emotions from deciding what Agile teams should work on by matching demand and supply in a visual, data-driven, quantitative way.
Quantitatively matching actual capacity to business demand with a dynamic cut line
When business leaders were too busy to collaborate in release planning, early adopters used the new page to present different scenarios instead of saying “We can’t do it all.” Executives were more engaged and appreciated the opportunity to review alternate, realistic options.
Last but not least, there’s an acute shortage of skilled development professionals. Businesses seeking to retain existing talent and attract new talent need to create an inviting development environment that respectfully balances employees’ time and capacity.
The capacity planning capability is the result of a year-long engagement with customers to understand how to best support Agile organizations in effectively leveraging the power of stable, cross-functional teams to meet growing and changing business demand. We’d like to extend a heartfelt thank you to the customers who helped us validate this functionality over the past year.
On June 17, Rally® Unlimited Edition customers will have access to the new Capacity Planning page and all the benefits that come with it — just contact your Rally Solution Architect to get the capability enabled in your subscription.
For more information about capacity planning for the fast-paced world, download the white paper.
A picture’s worth a thousand words — unless, of course, it conveys outdated or incomplete data. With LeanKit’s new Custom Reporting, you can answer your burning questions faster — and accurately. LeanKit’s Custom Reporting solution offers quick insight to help you: Highlight organizational trends with cross-board reporting Meet your unique needs with custom reports, charts, and graphs […]
As more of my clients transition to agile, many of them have a fascinating question:
How do I assess who is doing what on my team?
When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation.
When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.”
Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not).
Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator.
What I see is that the managers want to control team membership. Instead, why not let the team control its membership?
I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback?
When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork. Or, they wonder if some people are wasting time.
If managers trust their teams, managers don’t need to worry about accountability. They don’t have to worry about people “wasting time.” Agile creates transparency, which helps people to learn to trust each other and know when they are working on relevant work or not. If you encourage the team to add pairing or swarming (or both), you have the recipe for whole-team work and team momentum.
I don’t know anyone who goes to work thinking, “How can I waste my time today?” Do you? (If you do, why is that person on your team?)
I know plenty of people who do waste their time, because of technical debt, or experts creating bottlenecks, or team members who don’t want to work as part of a team. I bet you know many of these people, too.
But I don’t know anyone who wants to go to work to waste time and collect a paycheck without doing anything. Sure, there might be some people like that. I don’t know any.
In an agile team, the team members know who works hard and who doesn’t. A manager could trust the team to handle their compensation.
And, that would mean the manager has to relinquish control of much of what managers have done recently.
- The manager would have to provide feedback and meta-feedback to people who want to learn how to provide and receive feedback.
- The manager might provide coaching as to how to work in a team effectively. (This can be tough if a manager has never been part of a team that worked well.)
- The manager would allow the team to control their compensation.
There’s more, and I’ll stop there.
What would managers do? They would stop interfering with the team’s progress. The manager might read “If Managers Don’t Give Performance Reviews, What Happens?”
Managers control much less in agile. Managers enable more. They have to trust the teams. This is a culture change.
If you can’t trust your agile team or its team members, there is something wrong. You can investigate and either fix (manage the project portfolio) or ask the team to fix it (maybe with retrospectives as a first step). If you need to know who is accountable for what, you are asking the wrong question. The answer might be you.
If you are managing an agile team and you want to know about individual work or accountability, ask yourself what you really need. Ask yourself if there is another way to obtain the results you want. Maybe you won’t waste quite as much time.
Being Product Owner is hard. Actually, that’s not quite true. Anybody can make a list of things to build, call it a backlog, and bring it to a few meetings every month.
Being a great Product Owner is hard. Development skills are essential, but it doesn’t matter how fast your team delivers and how good your quality is unless you’re delivering the right thing every day. Identifying and expressing that “right thing” at every level of detail is a big job.
To improve our CSPO classes and our PO coaching, Bob and I made a tree of the skills that the best Product Owners use. While there are over two dozen skills on the tree—see, it’s not an easy job!—here are 5 you can work on to have an impact on your team right away.Skill #1: Clearly express the connections between larger business goals and small backlog items
Many POs are good at making a business case for a project, but end up with a backlog of items that seem disconnected from that larger goal. By the time the team gets a few sprints into the project, half the team (and maybe the PO) have forgotten the business case and are just delivering on the details. They can no longer see the forest for the trees.
A great PO distills the business case into a short vision, makes it visible, and can point to it to explain every little thing on the backlog.
There are lots of ways to write a vision. One of my favorites is a variation on the elevator pitch template from Geoffrey Moore’s Crossing the Chasm. It goes like this:
FOR target customer
WHO need or dissatisfaction
product name IS A category
THAT key benefit (not key features, but what the features allow the customer to do).
UNLIKE alternative way of meeting the need
OUR PRODUCT how it’s better for the customer than the alternative.
Can you answer all the questions posed in this template? Could any member of your team? If not, you’d do well to fill in the template.
This doesn’t always make the most pithy, literate vision statement—it can sometimes be too formal or clumsy—but I love how it makes you answer some key questions about your product in a couple sentences. A slightly clumsy vision statement is better than none at all. And once you have a draft in this format, you can revise it read better.
Here’s an example for our Humanizing Work Conference:
FOR Agile For All alumni
WHO want to get better at their work
Humanizing Work IS AN Agile conference
THAT allows Agile For All alumni to learn advanced content from us and from other like-minded Agile practitioners.
UNLIKE a public Agile conference,
OUR CONFERENCE is built from the ground up on brain-friendly accelerated learning methods and has attendees who share a common language and understanding of the principles behind Agile (which lets every session go deeper).
This vision gives us a filter for every decision we make about the product. It prompts us to ask questions like:
- Is that session relevant to Agile For All alumni?
- Is it advanced content, or would they already have learned it in one of our classes?
- Is ______ brain-friendly or just how conferences always work? Could we make it more brain-friendly?
Sometimes you have more than one kind of target customer. For the Behavior-Driven Development with Cucumber book I’m writing with Paul Rayner, we’re targeting people in four different roles who have different needs. BDD is a practice for collaborating across roles, so we have to meet the needs of all these roles. So, we drafted four parallel visions, like this:
We had a client in education software who had to do this for students, teachers, and school administrators.
Once you have a vision statement, make it visible. If you’re on a colocated team, make a big poster and stick it on the wall. As a distributed team, we tend to use tools like Google Docs, Slack, and email. But when we’re together, we collaborate with paper.
Having a visible vision statement is great. But take it a step further: explicitly connect the vision to the details in your backlog. Say things like, “We’re doing this user story because it helps differentiate us from [alternative],” and, “Remember, we’re not building this story for everybody, it’s just for [your target customer], so we don’t have to do [some variation your target customer doesn’t need].”
You can practice this today:
- Write a vision statement if you don’t have one already. Don’t worry about making it perfect, just fill in the blanks for a first draft.
- Make it visible to your team. Incorporate their feedback to improve the vision.
- Go through the top items on your backlog. For each one, write a sentence or two explaining how that backlog item moves your product towards the vision.
I was once coaching a PO and a couple of developers as they groomed their backlog. I noticed that all their user stories looked like this:
As a user, I want some new feature for the team to build.
Yes, their stories actually said “as a user,” but that’s not what struck me. I noticed none of their stories said why the user wanted the thing. There was no “so that” or “in order to.” So, I asked them why.
“Because they don’t need to know,” responded the PO, “I tell them what to build, and they build it.”
I looked over at the developers, expecting to see shock and dismay at being treated like short order cooks, and was suprised to see them nodding.
“Yep,” one said, “she tells us what the user wants and we build it.”
Just to see if it might make a difference, I asked them to try adding a “why” statement to their top story. We quickly realized that the PO had a similar relationship to her stakeholders—they tell her what they want and she goes to the team to get it built. But we talked about it for a few minutes and came up with a plausible “why.”
The moment the PO finished typing the change into their backlog tool, one of the developers said, “Oh, that’s what you’re trying to do. We can do it this other way for a tenth of the cost of what you asked for.” So they changed the story to accomodate the new “what” and went on to deliver the value for a much lower cost.
By adding the “why” to their story, this team was able to collaborate with their PO to make a better “what” than either could come up with on their own. Writing stories in a way that enables this collaborate is a key PO skill.
Here are two simple ways to do this:
- Make sure each story has a clear “why” somewhere that explains the larger value or goal for the user. Explicitly connect the story to the product or release vision if you can (as I described in the previous skill).
- For the “what” in the story, try describing the task the user is trying to accomplish rather than the feature in the system. Ask yourself, “Am I telling the team what to build, or am I inviting them to empathize with and solve a problem for a user?” The more your language in the story trends towards the latter, the more opportunity you have for the team to solve the problem in a way you haven’t imagined.
Whether it’s from customer feedback, your competitor’s latest release, a new technology, or a new regulation, the world changes in a way that affects your backlog.
Great POs respond to change by changing their backlog so it always reflects the current reality and your current knowledge. Merely competent POs add new backlog items and reprioritize in response to change, but they tend to leave out-of-date cruft in their backlogs. (Bad POs ignore change and treat the backlog as a big up front project plan, but you wouldn’t do that.)
The key to being able to respond to change without having to throw lots of work away is avoiding detail in your backlog until it’s unlikely to change. I know, that almost sounds too easy to be a real thing, but we have several clients doing it well.
Here’s how you do it:
- The top of your backlog should be user stories, sized small enough that 6–10 could fit into a sprint and with enough detail that the team feels comfortable committing to them in sprint planning. Most backlogs should have about 2 sprints worth of stuff like this on the top of the backlog and no more. When you get down to this level of detail beyond a few weeks in the future, you’re very likely to have to throw something away when the world changes. Small details are fragile to small changes.
- Beyond 2 sprints, don’t use user stories. Instead, use minimum marketable features, or MMFs. An MMF is a small (minimal) change in system behavior (feature) that’s valuable enough actually get in somebody’s hands (marketable). You can prioritize these in your backlog. You can size them against each other just like you do with stories. And you can measure the relationship between feature size and story size as you split these MMFs into stories. MMFs are usually stable enough to use in your backlog out to about 6 months.
- Beyond 6 months, even MMFs are too volatile, so just keep a cloud of themes you want to address over the next year or two, with the most likely ones at the top. This will let you keep your product strategy in mind without wasting time on detail that’s likely to change.
- Finally, keep a list of things you’re intentionally leaving out of your backlog. You can revisit this list quarterly to see if they need to get promoted to the backlog, but you won’t need to waste energy on these items every time you look at the backlog. In his Getting Things Done personal produtivity method, David Allen calls this the “Someday/Maybe List.” I have one that includes things like, “Learn German.” It’s something I might like to do someday, but don’t want to think about today.
Your backlog ends up looking like this, with small items on top, larger items further down, and eventually a cloud of options to draw from:
(I teach more about how to structure your backlog in this way, how to visualize it on a kanban board, and how to forecast releases over it in my 80/20 Product Ownership online course.)Skill #4: Say “no” appropriately when necessary to maximize the value of your product
We give out a lot of NO buttons at conferences and in our classes. They say “no” 10 different ways, and Product Owners love them. They’re a joke, but they highlight a real issue.
If you don’t say “no” intentionally, you can’t say “yes” intentionally. You still don’t get everything done, but instead of choosing what to say “no” to, you let it happen by accident or let others choose.
Great POs have the skill of saying “no” without being a jerk. Here are a few ways to say “no” when someone wants to add something to your backlog:
- “I’d like to add that item to the backlog, too. What should we pull out to make room for it?”
- “That’s not a priority for us at this time. We’re choosing to focus on [current focus] right now. Let’s consider it again [next month/quarter/year/whatever].”
- “Sorry, that doesn’t fit our current vision.”
- “Help me understand why you want this. Maybe there’s another way to solve this problem.”
- “No, because [reason why you’re choosing not to put this item in your backlog at this time].”
- “Here’s another thing you can do in the product that might help…”
- “Here’s another similar item in the backlog…”
- “Maybe we can include part of that in [another closely-related backlog item].”
You’re the Product Owner because your business leaders trust you to make the best decisions about the direction of your product. Accept that responsibility and be deliberate about what you say “yes” to and what you say “no” to.
You can practice this right away by looking at your backlog for things you’d like to say “no” to now. Either remove them if you the authority to or plan how you’re going to talk to the stakeholder if you don’t.
(If you’re not actually trusted to make decisions about what goes in your backlog, by the way, that’s an issue to address directly. No amount of skill in saying “no” fixes that one.)Skill #5: Split big slices of value into small slices of value
Of all the skills a PO can have, this is the one that makes the great POs stand out. Great POs can take a big idea for a project and find early high-value, high-learning MMFs. They can take an MMF and find the essential user stories that make it marketable. They can take a big user story and split it into several small stories. And they can take even a small story and help the team build it in small, valuable slices.
Getting good at splitting has several benefits:
- It helps you identify the low-value parts of every project, feature, and story so you can avoid ever building them.
- It helps you find the high-value parts so you can build them first.
- It helps you avoid building components, infrastructure, and technical tasks that don’t directly deliver value.
- It reduces the risk in each sprint because you’re not betting the whole sprint on one or two stories. Getting 9 of 10 stories done is better than getting 1 story 90% done.
- It gets you to done much faster, which enables earlier feedback and more frequent releases.
I’ve written a lot about how to split a big user story into smaller stories. My articles and posters on story splitting account for almost half the traffic on our website.
If you have stories near the top of your backlog that are larger than ⅙ of your team’s velocity, try using my story splitting patterns to find some small, valuable slices inside those stories.
If you’ve gotten value out of my story splitting material and you’d like to learn more about splitting at the other levels of detail (or just hone your story splitting skills), check out my new online course, 80/20 Product Ownership. In this self-paced online course, I share a set of splitting and backlog management techniques that, until recently, were only available through in-person training and coaching with me.
“Coaching is the universal language of change and learning.” – CNN
In our previous post, we’ve provided you with some hints on how to build a good agile team that will work like a well-oiled machine. We agreed that building a team isn’t very easy, but it’s still feasible and necessary in order to achieve extraordinary results.
As a matter of fact, pulling people together and maintaining the team in a good spirit can be even harder. This is the time when agile coaching can give us a helping hand.
Anthony Robins (famous life coach) coined a term CANI – which is an acronym for Constant And Neverending Improvement. The key word here is an improvement. Therefore, we cannot say that agile is yet another process – an agile approach is a means of improving everything – c o n s t a n t l y.
Here we have a space for agile coach that can help the team to understand why, what they’re doing really matters, and why the agile way matters.
But what is an Agile Coaching, anyhow?
Agile coaching competency framework
Agile coach should aim to “grow a productive Agile team that thinks for itself rather than relying on you to lay down the agile law”.*
As we can see it’s not about simply showing the right path but rather helping the team to find their own way within an agile environment.
We can boil down the agile coaching to five elements:
Mentoring – a coach is a helping hand that can provide the team with necessary advice when it’s needed. It’s quite critical for a coach to have a wide range of knowledge and experience not only in the scrum methodology. Moreover, agile coach needs to lead by example, simply walk the walk, so to speak. So if a coach wants to teach about agile principles, he needs to follow the agile rules himself during daily work.
Training – agile coach needs to pass all necessary knowledge and enforce it into practice. It’s not a rocket science, every team is different, made up of various people with different experiences and abilities in acquiring knowledge. That’s why a coach needs to remember to adjust the form of information flow to a particular team.
Management – however not managing people but managing the process itself. As we have agreed – agile is a process of constant improvement.
Coaching – it’s a partnership process, during which a coach supports the client (can be a group or a team) in making the best use of his potential in order to achieve particular goals. How does it get done? By asking proper questions, by understanding the team’s flow and all the habits that come with daily work. A coach should help his client transform to the point where he wants to be.
Assistance – coach needs to facilitate with solving all the issues that will occur somewhere along the line with all his experience and knowledge.
Well, considering the above fact it seems that being agile coach is not a piece of cake. But who said it’s going to be easy anyway? :)
It appears that the hardest part in becoming a good, agile coach is developing all of the earlier mentioned competencies. Agile coach needs to have a wide range of knowledge as well as skills to perform all those roles.
So what skills are important to be developed for agile coaches? As Rachel Davies wrote:
- Working with people: listening, giving feedback, asking questions, building trust and rapport
- Facilitating change: enlisting support, reaching agreement, spreading success, learning from failure
- Systems thinking: seeing the bigger picture, identifying levers for change, communicating danger signals
Benefits from agile coaching
Implementing scrum in an organization is often perceived as a remedy for all the problems that a company suffers from. But (as you may have experienced in your companies) implementing scrum isn’t a very easy task and can entail a lot of other problems.
That’s why agile coach is a must!
So here we have some of the benefits that a company can get from implementing an agile coaching:
- An outside view – coaches bring a new perspective to the organization, team and individuals and they remove intrinsic bias and interpersonal issues.
- New opportunity for improvement – a good coach provides learning and training for the employees and develops their skills
- Facing the problems – agile coaching creates an environment that allows teams to face the difficulties and work on a proper solution instead of sweeping problem under the table.
- Saving time and money – coaches bring both the tried and the new practices and processes to a team and organization, reducing the degree of trial and error commonly found in homegrown experimentations.
One size doesn’t fit all…
Just remember that agile coaching is not a holy grail for all the problems that you might encounter with your team.
“Every technique is working and is not working at the same time”
which means that a technique or a solution that was used for one team can work and, on the other hand, can be useless for another team. It’s all about the context and about people.
Picture (with small changes) courtesy of Brain vector designed by Freepik
At Ivar Jacobson International (IJI) we have been involved in many agile adoptions ranging in size from single teams to entire IT development organizations. The single biggest problem we see is organizations not understanding why they are changing the way they work – they don’t visualize the goal, set any targets, measure the improvements, nor demonstrate the benefits generated.
This isn’t a problem where an empowered team is looking to improve their own way-of-working. However, it is often a showstopper when attempting a broader adoption, such as an organizational transformation or where the team is not yet empowered.
The key here is to establish a set of actionable measures to drive the change and inspire the teams. These should explicitly support the principles and values being promoted and challenge the teams to improve.
In this article we will look at one way to establish a measurement dashboard to support your agile transformation.
What Should You Measure?
To gather empirical evidence of the effect of the transformation you need to have both:
- Measures of the improvement – measures that quantify how well the transformation is going, the amount of cultural change and benefits being generated. For the teams to be truly empowered these measures should be kept as process and practice independent as possible.
- Measures of the mechanisms that produced the improvement – measures that quantify what is being used where, demonstrate the uplift in capability across the agile teams, and show whether the transformation is on track to achieve self-sufficiency
These measures will complement and, in many cases, reuse the measures that are being used by the teams to drive and control their work.
In this article we will focus on how to measure the improvements. The sad thing is that there is no standard set of improvement measures that can be promoted or prescribed as suitable for all agile transformations. Each agile transformation is different; with different goals to achieve and problems to address. What is needed is a set of measures focused on the improvements that need to be made. This set of measures will need to be inspected and adapted to ensure that it continues to be relevant as the transformation progresses and the initial improvements are built on to generate more and more business benefit.
Measuring the Improvement: Building an Improvement Dashboard
Our preferred approach to establishing an improvement dashboard is to use our Better, Faster, Cheaper, Happier framework. This is summarized in Figure 1 below.
This is a simple framework that helps organizations produce a balanced set of improvement measures that are aspirational rather than operational. It is important to achieve a balance between the measures, so that you don’t increase delivery speed whilst sacrificing employee or customer satisfaction, or improve quality whilst lowering productivity.
This proven framework helps organizations to identify and implement practical measures that:
- Focus on the real business drivers, goals and benefits
- Measure the things that really matter – the effects not the causes
- Show whether things are really improving – eliminating seasonal fluctuations by looking at performance over a year, not a week or month
- Consider how people feel – gathering both qualitative and quantitative data
- Are simple and easy to understand – not complex derived measures and indexes
- Don’t depend on using particular processes and practices – allowing the old and new worlds to be compared
- Have relevance to the business – clearly showing where the business would like to see improvements
- Have targets and obvious trends – the on-going trends are more important than point measures
The result will be a set of measures and targets that everyone can understand and support.
Some Illustrative Measures
There are lots of measures that could be relevant to your transformation. For illustrative purposes Figure 2 shows a compilation of some of the measures that we have seen to be popular within organizations embarking on large-scale agile transformations. For example, when starting out nearly everyone targets on-time delivery before focusing on cycle times – as a wise man once told me less late is still late.
A couple of things to note about this dashboard are:
- This is an illustrative dashboard and has never been used in this form by any specific organization. All the customers have used some of these measures, but they have also all had their own specific measures to address their specific problems.
- This probably lists too many measures for use at any one time. Most adopters start with eight or so measures, which is more than adequate to cover the four quadrants. At IJI we have built up a library of more than 30 candidate measures that support common organizational goals. The important thing is to understand the goals and the underlying concerns rather than to just go shopping for measures.
The measures shown in Figure 2 are:
- On-Time Delivery – Percentage of releases that are released on-time
- Escaped Defects – Mass of defects that escaped from 1) development teams to acceptance test and 2) from acceptance test to live in the last year
- Meets Business Needs – Survey of whether the customers think the software delivered met their business needs
- Level of Priority 1 Incidents – Number of priority 1 incidents reported in the live environments in the last year
- Time to Production – Number of weeks it takes for a project to get a release into production once the project is started banded by overall project cost
- Decision Making – The time it takes to commit to progressing a project or producing a release from decision to evaluate the request
- Timeliness of Delivery – Survey of whether the customers think that the software was delivered in a timely fashion suitable for their business
- Improved Value for Money – Survey of whether the customers think that the software represents good value for the money spent
- Overheads – The cost of non-productive work done by the development teams (such as fixing escaped defects, support, administration etc.)
- Stabilisation and After Care – The cost of stabilising and supporting releases in the warranty period after they initially go live
- Business Satisfaction (organisational level only) – Survey of whether IT’s business partners are happy with the service provided by IT
- Team Satisfaction – Survey of whether the teams developing the software are satisfied with the way that they work
- Customer Satisfaction – Survey of whether the business representatives and users directly involved in the teams’ work are satisfied with the way the teams work
It is important that all the teams, projects and programs within the scope of the transformation, regardless of their level of agility or buy-in, can use the dashboard. For example, KPN in Netherlands was one of the first organizations to use the framework. They applied it to more than 14 programs and 400 projects within their IT Innovation organization. In the spirit of autonomy and empowerment the programs were allowed to opt out of the transformation if they were confident they could meet the targets. Unsurprisingly the teams that decided to stay with a waterfall way of working showed little or no improvement across the board falling well short of the average performance in all cases. For more on the KPN measurement story see http://www.ivarjacobson.com/resources/resources/case_studies/
The dashboard is created through a series of short workshops where the objective is to understand the most important areas to improve, and to identify practical, intuitive measures to evidence the improvements. The people involved should include leaders, executives, customer representatives, senior managers plus other key stakeholders with a specific interest in the improvement goals and results.
The workshop helps participants to understand the business drivers, goals and needs, and set some meaningful improvement targets. It starts by simply brainstorming what the words better, faster, cheaper and happier mean to the participants focusing the conversation onto the goals of the transformation, and proceeds through various rounds of discussion, consolidation and voting to identify key areas for improvement. This helps to quickly establish what measureable benefits are expected from the transformation and makes sure that they are aligned to the business goals.
The end result is an overall dashboard containing a set of intuitive measures that support the organizational goals and present the overall targets for the next stage of the transformation. This enables everyone to see the targets, the current status, and the improvements taking effect. Typically the measures are captured on a monthly basis providing an instant feedback mechanism on the effectiveness of the approach and whether or not the desired improvements are materializing.
A truly agile organization is a learning organization that is continually refining and improving all its practices. It is an organization that is focused on continuous improvement and delighting its customers.
To reach this promised land you need a laser-like focus on results, whilst not forgetting why you are implementing an agile approach. Too many agile transformations stall when they are unable to demonstrate that the new way of working is any better than the old way. The mistake they make is to think agility is an end in itself rather than an enabler for better business performance. Quantify the results you are looking for and make sure you measure the effect of the transformation.
It’s astounding how many agile transformations fail to track the benefits they are generating, and in many cases seem to leave the organization no better off than they were before. The people involved, particularly the sponsors and other executives, can also be very impatient. Creating an agile organization is not something that happens overnight. Agility is no silver bullet and not every agile team, or project, will be successful. Patience is needed to see the transformation through and reap the full benefits of agility. Measurement is needed to make the benefits visible.
In our experience the biggest benefits are achieved in the second year as agility becomes business as usual and the effects of agile working ripple through the value chain. Sadly if you don’t demonstrate how you are going to measure the improvements and make them relevant to the business you often don’t get a second year.
I was teaching a private class a few weeks ago and a student in the class mentioned that his company had “already failed at Agile three different times.”
The way the statement was phrased really struck me. It made me very aware of my own opinions about Agile adoption and taught me a little about how this particular student, and possibly the organization, felt about adopting Agile.
What struck me was how easily the previous efforts were declared failures. If they truly had failed, there was no way I’d have been in the room teaching a private CSM class. It is possible that the company did not fully reach the perfect state of Agile nirvana and was not able to enjoy the bliss of a friction-less work environment populated with completely realized, high-performing teams of enlightened humans who delivered shippable product every sprint in a self-organized, cross-functional manner. Instead, they learned how not to transform the company… which is not a bad thing, because every misstep gets them one step closer to the solution that will open the lock (or at least a part of it.)I have not failed. I’ve just found 10,000 ways that won’t work.
Let’s say you have a guy who loves to sit on the couch binge watching old TV shows while jamming Ho Hos and Mountain Dew down his throat all day. He hears about people running marathons and decides this is for him. He goes to the mall… buys some expensive running shoes, a sweat suit, special moisture wicking socks… the whole bit. Then he stops by the “24 Hour Buffness” gym (which, shockingly is having a new membership special) and he signs up for a yearly membership. Then he goes home, puts on his new running shoes with the special moisture wicking socks, his new track suit, grabs his 24 Hour Buffness Membership Card, plops himself down on the couch, cracks open a fresh can of Mountain Dew and a brand new Ho Ho. Then he fires up Netflix and puts on The Rockford Files, Season 5, Episode 4… The one where Tom Selleck guest stars as horribly annoying Lance White. Two days and 12 episodes later, our man realizes he’s not been to the gym, is not in shape, but seems to have consumed his weight in Ho Ho’s. If you ask him about it, he’ll explain how his situation is different, he can’t just start exercising like everyone else, The Rockford Files is not going to watch itself and let’s face it, that Lance White episode is a critical moment in Detective TV History. No Lance White, no Magnum. No Magnum, no Simon and Simon/Magnum mash-up episode… and then where would we be?
The real question is, has the “get in shape and run a marathon” project failed at this point? Or has he just not figured out the right way to get him motivated to change his lifestyle yet?
Now… imagine you had a building with 1,000 people just like him. Has the entire building failed? No… we just haven’t figured out the right way to make it work yet.
Change of any kind is difficult. Just because it doesn’t completely stick on the first try doesn’t mean it has failed or it didn’t work. It just means you did not figure out how to make it work YET.
And if you happen to work in an organization that has coaching and/or training for Agile, take that as a very positive sign. If the organization is willing to commit at that level, it’s a very good start. There are many places out there that are still convinced they don’t need help figuring this out.
Whether you want to call it transformation, adoption, “Project Nimble”, or whatever… the journey from a traditional approach to Agile is a long one. Transformation has to occur at multiple levels and it requires deep change to work practices and work culture. It may not happen all at once, it may be too tall of an order to just completely go Agile all at once. You may need to do it in stages (Basecamps). Your organization, like many others, may go through a number of attempts before things begin to stick.
If you know the old way doesn’t work, you have to make a choice. This choice takes place at an individual as well as an organizational level. Do you want to keep working in the old way, with annoying, but familiar pain? Or do you want to take a chance at trying something different that just might offer you a path to a better world of work? If you want the latter, you need to be willing to work for it, be patient and commit to keeping at it until you reach your goals. And, like any good sales person will tell you, No just means you haven’t figured out the right way to ask the question yet. When you do find it, they’ll say, “Yes”.
The post Agile Transformation … Learning What Doesn’t Work Is The Key To Success appeared first on LeadingAgile.
A modern leader is someone who succeeds through the achievements of her employees. A great leader is someone that sets the direction and supports the environment in which the employees can act and evolve. A great leader is someone that sets the boundaries for the team, but leaves space and freedom for the employees to take responsibility and improve.
To grow into a modern leader you will likely need to unlearn what you were taught at business school and by traditional managers who mentored you. Read more from Peter Hundermark’s latest blog post on ‘Growing Leaders‘.
Leading Self-Organising Teams course Masterclass for Agile leaders and professionals
- Understand the principles of Agile Leadership
- Learn and apply state-of-the-art leadership tools
- Enrich your skill set through practical role plays
- Cope with tricky situations and identify blind spots
Only a few spots left, so be sure to book your place and get equipped to face the complex leadership challenges of the 21st century.
When: 07-08 July 2015
Where: FNB Conference & Learning Center, Sandton
Certified Scrum Master (JHB)
23-24 June 2015
Certified Scrum Product Owner (CPT)
29-30 June 2015
Leading Self-Organising Teams (JHB)
07-08 July 2015 (Only 6 spots left!)
Visual Facilitation Foundation Workshops
27 July 2015 (CPT)
30 July 2015 (JHB)
Visual Facilitation Advanced Workshops
28 July 2015 (CPT)
31 July 2015 (JHB)
The post News update 2015/06 – Creative Visualisation Workshops appeared first on ScrumSense.
My daughter’s FFL Lego Club is over for the year, but I wanted to two helpful debugging things I learned along the way, that were especially helpful for newer kids.
This was the first year for a group of 5th and 6th graders and I noticed many of them ended up with some long procedural blocks of code to navigate the robot through obstacles across the board and back to the base. A really common problem was they’d make some progress, and then come back to the table only to discover the robot didn’t do what they expected after a “small change.”
The first fix for this was actually saving a copy off before making significant changes, just giving it a new name. The Lego LabVIEW environment didn’t make this easy as you have to cut and paste the blocks by hand into a new program, but it saves a lot of time with the kid’s longer programs. I’ve used Git for the same effect, but source control isn’t the focus here.
A second quick win was testing with the robot connected. Our boys and girls were very set on the program, download, run to the table loop, but I eventually had a few of them persuaded to test with the robot just connected via USB. The best part of this is you can select a single block and then run just that block with the robot. We used this several times to troubleshoot issues with arms that swung back too far and got stuck on lego pieces, which halts further execution and doesn’t give much feedback on what’s wrong.
Finally was the one I had the most fun with. Many kids’ programs had dozens of blocks connected. Often they would forget where they added tweaks to turn left, spin, or adjust the shooting arm. As a lover of sound effects I suggested adding sound effects before and after they added their tweaks so they’d know several things:
- Did my changes actually get loaded on the robot?
- Did my changes improved the program?
- Exactly where to tweak the program again if it just needed another adjustment.
The sounds were fun on their own and they can easily be deleted when the program is ready to go.
The next time the team says “we can’t estimate without better requirements” what they actually mean is, “this is crazy, but hey…if you think you can accurately predict all the exact requirements and you can guarantee that nobody in this company will change their minds about those requirements between this moment and forever, then we’ll give you an estimate to hang your hat/noose on.”
Every group responsible for the creation and delivery of software (or any complex/creative product for that matter) will experience dissonance between the need to plan and the need to obey the laws of nature which prevent us from travelling through time and future-telling. Business leaders have to finance the development of product; creative and technical leaders have to solve complex problems amidst dynamic, unpredictable, circumstances. These conditions manifest as a dichotomy which is difficult to mediate (at best) and/or downright toxic (at worst).
On one hand, a common sentiment among project managers is: “The problem I have with the release planning stage is that without clear requirements, the developers don’t like to give estimates, even with story points.”
On the other hand, a common sentiment among developers is: “Stakeholders don’t understand what they’re asking for, if they knew the complexity of our technology they wouldn’t be asking those questions.”
If developers don’t like to provide estimates, it is likely because others in the organization have used their estimates as though they are accurate predictions of future. Thus, when said estimates turn out to be inaccurate they are used as punitive metrics in conversations about “commitment” and “velocity” and “accountability”.
Point of order: NOBODY CAN PREDICT THE FUTURE.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
How long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.Question
After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?Answer
Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.
For your team, it is unlikely that the underlying problem is that there isn’t enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems:
Our User Stories are Too Big
If your user stories are too big, then you won’t be able to complete them in a sprint. Luckily, this is a solvable problem. Have a look at SmallerStories.com for techniques that will let you split any user story into small user stories. Practice these techniques, and you will be able to have meaningful user stories just as small as you like. My suggestion is to get the user stories at the top of your product backlog to be small enough that the development team can comfortably finish four to six each week.
Testing Takes Too Long And We Can’t Finish It All In The Sprint
First, make your stories smaller. When I said the team needs to be able to complete four to six stories each week, this includes the testing; dev-done isn’t done.
Next, work to have the development team swarm on completing the stories that are already in progress, instead of letting the coders start new stories. This makes testing, including that boring regression testing, everybody’s job. Yes, I know, developers don’t like testing. This is exactly why I want them responsible for the testing, especially the regression testing. You see, developers often think that the answer to most problems is to write code; in this case they are right! The best way to solve the regression testing problem is to automate those tests. With the regression tests automated, your professional testers are now free to focus more of their time creating acceptance criteria for upcoming stories, so that the whole scrum team will better understand and agree what will be needed to truly complete those stories. This will lead to fewer surprises and disagreements, and more stories done.
Our Meetings Are Inefficient And Take Too Long
This is a common problem, especially for new scrum teams. The fix is to learn how to have focused, efficient meetings. This takes practice. This takes facilitation, by the scrum master and others on the scrum team. When teams decide to make their sprints longer, in the hope that they will then have more time available for ‘the work’ they usually make things worse instead of better. The problem is that longer sprints have more unknowns and thus are harder to plan. It takes more than twice as long to make a plan sufficient for two weeks than it does to make a plan sufficient for one week. Figure out what’s wrong with your meetings (e.g. You keep getting derailed into design discussions), and fix that.
Our Team Is New And Still In The Steep Part Of The Scrum Learning Curve
It’s true that when a team first starts using scrum, they will struggle. It’s new. They are learning how to do scrum, and that’s hard at first. At first, it actually slows us down, as we navigate the learning curve. My experience is that it typically takes three to six sprints before a new team starts to get over that learning curve. Notice that this is sprints, not time; it’s the number of times through the cycle that matters. With one-week sprints, a new team can get through the learning curve in three to six weeks. Choosing two-week sprints will double the amount of time needed to climb up that learning curve.
My advice is to stick with your one-week sprints and fix the problems that scrum is making visible to you.
Every few months we run a relational to graph meetup at the Neo London office where we go through how to take your data from a relational database and into the graph.
We use the Northwind dataset which often comes as a demo dataset on relational databases and come up with some queries which seem graph in nature.
My favourite query is one which finds out how employees are organised and who reports to whom. I thought it’d be quite interesting to see what it would look like in Postgres SQL as well, just for fun.
We’ll start off by getting a list of employees and the person they report to:
SELECT e."EmployeeID", e."ReportsTo" FROM employees AS e WHERE e."ReportsTo" IS NOT NULL; EmployeeID | ReportsTo ------------+----------- 1 | 2 3 | 2 4 | 2 5 | 2 6 | 5 7 | 5 8 | 2 9 | 5 (8 ROWS)
In cypher we’d do this:
MATCH (e:Employee)<-[:REPORTS_TO]-(sub) RETURN sub.EmployeeID, e.EmployeeID +-------------------------------+ | sub.EmployeeID | e.EmployeeID | +-------------------------------+ | "4" | "2" | | "5" | "2" | | "1" | "2" | | "3" | "2" | | "8" | "2" | | "9" | "5" | | "6" | "5" | | "7" | "5" | +-------------------------------+ 8 rows
Next let’s find the big boss who doesn’t report to anyone. First in SQL:
SELECT e."EmployeeID" AS bigBoss FROM employees AS e WHERE e."ReportsTo" IS NULL bigboss --------- 2 (1 ROW)
And now cypher:
MATCH (e:Employee) WHERE NOT (e)-[:REPORTS_TO]->() RETURN e.EmployeeID AS bigBoss +---------+ | bigBoss | +---------+ | "2" | +---------+ 1 row
We still don’t need to join anything so the query isn’t that interesting yet. Let’s bring in some more properties from the manager record so we have to self join on the employees table:
SELECT e."FirstName", e."LastName", e."Title", manager."FirstName", manager."LastName", manager."Title" FROM employees AS e JOIN employees AS manager ON e."ReportsTo" = manager."EmployeeID" WHERE e."ReportsTo" IS NOT NULL FirstName | LastName | Title | FirstName | LastName | Title -----------+-----------+--------------------------+-----------+----------+----------------------- Nancy | Davolio | Sales Representative | Andrew | Fuller | Vice President, Sales Janet | Leverling | Sales Representative | Andrew | Fuller | Vice President, Sales Margaret | Peacock | Sales Representative | Andrew | Fuller | Vice President, Sales Steven | Buchanan | Sales Manager | Andrew | Fuller | Vice President, Sales Michael | Suyama | Sales Representative | Steven | Buchanan | Sales Manager Robert | King | Sales Representative | Steven | Buchanan | Sales Manager Laura | Callahan | Inside Sales Coordinator | Andrew | Fuller | Vice President, Sales Anne | Dodsworth | Sales Representative | Steven | Buchanan | Sales Manager (8 ROWS)
MATCH (e:Employee)<-[:REPORTS_TO]-(sub) RETURN sub.FirstName, sub.LastName, sub.Title, e.FirstName, e.LastName, e.Title +----------------------------------------------------------------------------------------------------------------+ | sub.FirstName | sub.LastName | sub.Title | e.FirstName | e.LastName | e.Title | +----------------------------------------------------------------------------------------------------------------+ | "Margaret" | "Peacock" | "Sales Representative" | "Andrew" | "Fuller" | "Vice President, Sales" | | "Steven" | "Buchanan" | "Sales Manager" | "Andrew" | "Fuller" | "Vice President, Sales" | | "Nancy" | "Davolio" | "Sales Representative" | "Andrew" | "Fuller" | "Vice President, Sales" | | "Janet" | "Leverling" | "Sales Representative" | "Andrew" | "Fuller" | "Vice President, Sales" | | "Laura" | "Callahan" | "Inside Sales Coordinator" | "Andrew" | "Fuller" | "Vice President, Sales" | | "Anne" | "Dodsworth" | "Sales Representative" | "Steven" | "Buchanan" | "Sales Manager" | | "Michael" | "Suyama" | "Sales Representative" | "Steven" | "Buchanan" | "Sales Manager" | | "Robert" | "King" | "Sales Representative" | "Steven" | "Buchanan" | "Sales Manager" | +----------------------------------------------------------------------------------------------------------------+ 8 rows
Now let’s see how many direct reports each manager has:
SELECT manager."EmployeeID" AS manager, COUNT(e."EmployeeID") AS reports FROM employees AS manager LEFT JOIN employees AS e ON e."ReportsTo" = manager."EmployeeID" GROUP BY manager ORDER BY reports DESC; manager | reports ---------+--------- 2 | 5 5 | 3 1 | 0 3 | 0 4 | 0 9 | 0 6 | 0 7 | 0 8 | 0 (9 ROWS)
MATCH (e:Employee) OPTIONAL MATCH (e)<-[rel:REPORTS_TO]-(report) RETURN e.EmployeeID AS employee, COUNT(rel) AS reports +--------------------+ | employee | reports | +--------------------+ | "2" | 5 | | "5" | 3 | | "8" | 0 | | "7" | 0 | | "1" | 0 | | "4" | 0 | | "6" | 0 | | "9" | 0 | | "3" | 0 | +--------------------+ 9 rows
Things start to get more interesting if we find the transitive reporting relationships that exist. I’m not an expert at Postgres but one way to achieve this is by writing a recursive WITH query like so:
WITH RECURSIVE recursive_employees("EmployeeID", "ReportsTo") AS ( SELECT e."EmployeeID", e."ReportsTo" FROM employees e UNION ALL SELECT e."EmployeeID", e."ReportsTo" FROM employees e, recursive_employees re WHERE e."EmployeeID" = re."ReportsTo" ) SELECT re."ReportsTo", COUNT(*) AS COUNT FROM recursive_employees AS re WHERE re."ReportsTo" IS NOT NULL GROUP BY re."ReportsTo"; ReportsTo | COUNT -----------+------- 2 | 8 5 | 3 (2 ROWS)
If there’s a simpler way let me know in the comments.
In cypher we only need to add one character, ‘*’, after the ‘REPORTS_TO’ relationship to get it to recurse as far as it can. We’ll also remove the ‘OPTIONAL MATCH’ so that we only get back people who have people reporting to them:
MATCH (e:Employee)<-[rel:REPORTS_TO*]-(report) RETURN e.EmployeeID AS employee, COUNT(rel) AS reports +--------------------+ | employee | reports | +--------------------+ | "2" | 8 | | "5" | 3 | +--------------------+ 2 rows
Now I need to find some relational datasets with more complicated queries to play around with. If you have any ideas do let me know.
There are plenty of people who would tell you that an Agile transformation should be conducted slowly and gradually. Not Physicians Mutual.Taking Center Stage at RallyON
This week at RallyON!™ 2015, our friends at Physicians Mutual will be up on the main stage, talking about their unique and successful approach to an Agile transformation. We’ll share that video later so you can watch for yourself! Meanwhile, here’s a sneak peek into the story.The Big Bang Approach
In just few months, Physicians Mutual’s Enterprise Technology Group (ETG) launched 14 teams simultaneously and started running coordinated midrange planning sessions to deliver business value faster. No pilot. No staged rollout. Just a deliberate, well-planned effort to adopt enterprise scale Agile and the determination to see it through.
We refer fondly to Physicians Mutual’s rollout as the big bang approach. And it worked. The group went from 4 to 6 major releases annually, plus minor releases at the end of each 3-week iteration. As a result, ETG delivers hundreds of roadmap items over the course of a year, and they’re doing it with higher quality.How Did They Do It?
There are many factors in Physicians Mutual’s success with Agile, not the least of which is the expertise and tenacity of the people. But there’s another secret ingredient to any successful enterprise scale Agile transformation that we call big room planning.
Big room planning gets everyone in the same room to plan the work for a release. It’s an opportunity to confront key risks and dependencies. It’s a chance to make unforeseen connections. And it is the place to link strategy to execution.
Physicians Mutual has been doing this successfully since launching its Agile transformation, and it’s keeping ETG moving in the same direction.Find Out More
This is a great story — one that we love to tell at Rally. We look forward to hearing the long version of the story straight from the team that made it all happen at Physicians Mutual.
On Thursday I was presenting at DevTalks Bucharest, a 550+ developer conference with four different stages. I shared the panel with a Sabin Popa (Cloud Strategy Leader at IBM) and there was supposed to be another panelist but they had withdrawn. The topic of the panel was, “Innovation and data privacy – Keeping innovation alive in Cloud!” We first presented a bit about ourselves and our companies, where I was talking about our three pillars: Sustainable Business (P1), Software Excellence (P2), and Social Justice (P3).Image courtesy of Phillipp Krenn (@xeraa)
I talked a lot about observations we see around the world with our clients – these stories really resonated with people, particularly because:
- It is based in reality (and not just sales demonstrations or fancy presentations)
- People are genuinely interested in what other people are doing around the world.
During the panel, I talked about the responsibilities that we have as developers for privacy, and the responsibilities that we have as educated citizens to get this on the agenda of our parliaments. I touched upon the idea of Datensparsamkeit and that we can use our knowledge to start raising awareness among our friends and families.
Although not meaning to, I found that I probably spent a lot of time talking on the panel – but mostly because both the moderator and the other panelist wanted to keep asking questions of me. I had suggested that Sabin also give his own thoughts about what they could be done about data privacy.
When we touched the topic of innovation in the cloud, the topic of certification came up – something that didn’t really surprise me. One statement was that all platforms would be certified in the future (for security) and that would be considered one form of innovation. Although useful, I challenged the position, talking about how certification gives false confidence – particularly in services and products where people are involved. I think certification is definitely useful for testing mechanical parts, for testing platforms and products that never change – but software is soft. It constantly involves and once a platform is certified, doesn’t mean it will continue to pass the same tests. I see a lot of companies sell certification as an easy answer and I believe it gives companies a false sense of confidence.
An interesting question posed to the panel is what would we do if we are asked by our company to do something that is borderline unethical but not doing the task puts our job at risk and the mention that there are many more people to do our role. This, for me, was an easy answer. I talked about our responsibility of being digitally-educated and responsible citizens of the world and talked about the bravery and confidence of people like Snowden. I challenged everyone we should think through the consequences of mindlessly doing tasks that we don’t believe in and not think about just the consequences of the job right now, but question the consequences for our family, friends and the world we are creating for future generations.