Skip to content

Feed aggregator

BigVisible Company Wide Retreat – BVCON!

BigVisible Solutions :: An Agile Company - Tue, 11/04/2014 - 16:48

Each day, our coaches are focused on customer issues, helping to spot and solve the impediments and barriers to agile implementations. But once in a while, these same coaches stop what they are doing and recharge their collective batteries at BVCon. BVCon is the name for our company retreat, a time for team building where […]

The post BigVisible Company Wide Retreat – BVCON! appeared first on BigVisible Solutions.

Categories: Companies

Some Thoughts on Agile Transformation in Big Companies

Leading Agile - Mike Cottmeyer - Tue, 11/04/2014 - 16:37

As usual… I’ve gotten a little sidetracked on my Agile 101, 102… series of posts. I’ve got the 201 post half finished, but haven’t been able to spend the time getting over the hump. That said, I want to divert just a little and talk about agile in general, explore some of what it is, and a little about where it’s going. I think we have created a bunch of confusion in the marketplace. I am under no illusions that this post will be the definitive explanation, but I spend a TON of time talking to people and level setting before I can have any kind of intelligent conversation on agile, so I want to explore some of the points that I think resonate.

Can We Define Agile?

First of all… back in my early, early days of community involvement at V1… I was really wresting with this untangling language around agile. I used to break the conversation into a few key areas: project management, product management, leadership thinking, and technical practices. Today, I find myself taking a slightly different angle. I tend to see agile discussed as a cultural phenomenon, sometimes as a set of practices, and sometimes as a way of structuring and governing how your company works. More often than not, agile is setup as a counterpoint to some of the most ridiculous examples of bad management we can come up with in an industry.

From my point of view, agile is all of these things collectively and none of these things individually. Agile is about having a rational system of work in place where people are engaged and can thrive, but one that produces the business outcomes that our stakeholders are counting on. When we get too myopically focused on one aspect over others, it is easy to start talking in platitudes and one-size-fits-all adoption approaches. Every organization I’ve ever worked with has been vastly different and, while certain patterns apply, solutions are always unique to the people that are impacted by the change.

The first line of the Agile Manifesto says that we are uncovering better ways of developing software by doing it and helping others do it. How we implement agile is supposed to change over time, and how it changes should be guided by the values and principles in the Manifesto. The challenge is that the values and principles are supposed to guide the practices and structures we choose to implement. The values and principles don’t live by themselves or in a vacuum. To successfully implement agile, we have to have a system of delivery and supporting practices which enable the values and principles to be lived out.

The Problem With Big Companies

I’ve been focused on what I call the ‘Big Company Problem’ since I left CheckFree more than 7 years ago. Back in the day, we were building complex systems of systems for the financial services industry. Products of products. Multiple overlapping and intersecting value chains. Heavy traditional governance and pockets of agile scattered throughout the organization. This was an environment with specialized business domain expertise, multiple diverse technology stacks, an organization that demanded 5 9’s reliability where downtime immediately impacted revenue and incurred penalties. How does one begin the process of agile adoption in any meaningful way in an environment like this?

Many of us suggest that ‘big and complicated’ is the problem and that we need to be ‘small and simple’. I agree… but, these companies ARE big and complicated so the question becomes HOW to help them become small and simple. Just saying BIG is bad and you should be SMALL doesn’t help. How do we get there? What is the path from A to B? Is adopting an agile value system enough? In the presence of the right value system, will the right delivery systems and practices emerge? In the presence of the right practices, can I impact the end-to-end system of delivery and make the cultural changes I need to make?

Culture First?

The problem with the culture first mindset is that there is practically no way to change enough hearts and minds to get everyone on board fast enough to produce results in the timeframes we are working against. Even if I could get everyone to adopt an agile mindset, we have real governance issues and audit requirements that often cannot be changed overnight. We have tightly coupled technology stacks, tightly coupled product requirements, imbalances in capacity and demand, and bottlenecks all over the place. Solving the problem is a matter of redesigning the system of delivery. Not everyone is an expert in designing systems, and even those that are don’t agree on the best path forward.

There are clearly some places where a culture first transformation can work. There are definitely some where it won’t. As an industry, we have to have an answer for when the scale and complexity are such that self-organization around the problem isn’t a viable approach. Again, the right company, the right business problem, the right underlying technology, and the right group of really smart people can get a ton of stuff done given the right degrees of freedom. There are some environments, though, where this is recipe for chaos. I personally think it is irresponsible to suggest that cultural transformation is going to fix this. We cannot always assume that if enough people ‘get it’ agile will begin to take hold.

Practices First?

Here is another one that I believe is driven by our long history of thinking of agile as a set of processes. Most top down organizations are accustomed to using process to pull together disparate working groups and coordinating activities across them to create larger deliverables or achieve broader organizational objectives. In many of these cases, the underlying organization, and maybe even the underlying organizational culture, doesn’t matter all that much. All we need to do is document a process that people can follow and, provided they actually follow it, we’ll get the outcomes that we desire. People assume that agile as a process will behave similarly.

Agile is different. You can’t take a set of functionally siloed teams, operating under heavy management control, traditional phase gate governance, fixed time, cost, and scope constraints, and tell them to do whatever process they want. You can’t tell them that agile is okay, but then hold them accountable to live in the same organization, under the same rules, and under the same constraints as a waterfall organization. The agile process in and of itself doesn’t make any rational sense outside the context of a team based organizational model, an agile governance framework, and a mindset that allows for some adaptation to the unknown. It doesn’t work.

Practices alone will never solve this problem. All we end up with is a bastardized form of agile where people go through the motions, but where agile doesn’t live up to the value that was promised. In order to do agile well, you have to have teams, you have to have backlog, and you have to have the ability to produce a working tested increment of product at the end of each iteration. This involves rethinking how you go about forming teams, how teams work together, and how value is coordinated. In the presence of teams and practices, I believe that the right thinking can emerge.

Structure First?

I’m a big believer that agile culture and agile practices are essential for long term sustainable organizational agility. That said, I don’t think you can train your way into it and I don’t think you can believe your way into it. I think you have to start with a team based organizational design where the flow of value is governed across teams using an adaptive governance model, based on lean/kanban principles, where WIP is limited, capacity and demand are balanced, bottlenecks are identified and dealt with, and management is invested in improving the overall system of delivery. Only within this kind of organization can an agile culture emerge and agile practices thrive.

I also don’t think that people intuitively understand these kinds of systems and I don’t think that most organizations will self-organize their way into them. Most people tend to think about optimizing what they can control and getting better only at what they are responsible for delivering. People are often self-interested and will consciously or sub-consciously advocate for system designs that are in their best interests. In the long run… forming teams, decoupling dependencies, reducing complexity, and creating an ecosystem where small, independent teams can self organize within their boundaries is the only model I believe will work.

So, I agree that we need to be small and simple, but getting to small and simple… much of the time… is a process of forming teams around business problems and technology, progressively decoupling them from each other, reducing dependencies, and dealing with bottlenecks. There are real issues facing large enterprises, there is a ton of momentum around the old way of doing things, real organizational and technological constraints, and just telling people to self-organize around a new system of delivery… one that they may or may not collectively understand… is often a recipe for disaster.

Structure then Practices then Culture

We do though have a bit of a chicken and the egg problem here. How do I get permission to start an agile transformation if I don’t have a leader with the right mindset to give it a try? I’d suggest that you at least have to have a leader that recognizes there is a problem and is open to alternative ways of solving it. I’d suggest you begin by focusing on your business goals, articulating a strategy to create a team based organizational model, and model based on iterative and incremental delivery principles, one that uses agile and lean methodologies for delivery and governance, but that operates within the operational and cultural constraints of the existing organization and it’s policies.

You teach this organization agile technical practices and management practices at the team level and adaptive lean governance practices at the program and portfolio level. You teach the organization how to deliver with reliability and predictability within that framework as you build trust in the new way of working. As we learn the capability of the new model and build trust with the organization, we create the opportunity to influence hearts and minds and create the environment where people feel safe to take chances and absorb risk with new ways of thinking that challenge their old ways of thinking.

The Role of Leadership

These kinds of changes have to be led with top down intent, but with a bottom up implementation. People have to be engaged and do ultimately have to be bought in. That said, buy-in will only come when people realize that the new system is working and the new system rewards the new behaviors. Once we have the rational team based system of delivery, new practices that support operating the new model, and a new mindset that enables us to unleash the power of the new system of work… we can start really improving as an organization and start tapping into the promise we’ve been reading about with agile all these years.

IMO… it’s not so important to talk about agile as structure, practices, or culture… it really is all three. It doesn’t matter if we are talking about agile as a set of management practices, an approach to product development, a leadership framework, or an approach to software craftsmanship. It is all of those things as well. But when it’s all those things living in an integrated system of delivery, where all the parts work together, when they are no longer in competition, where we really start to see the value. Things have to work as an integrated whole. It’s the working together as an integrated whole that is going to make this take off. Not just some team level agile practices or pockets of agile mindset in a vacuum.

Maybe this is all obvious, but there is a lot of debate about where to start with your agile transformation and what’s important to focus on first. If not debate, then different messages and approach in the marketplace around what works. I think that many folks work in broken organizations and can’t see a path forward… because without the support and direction of your senior leaders, nothing I’m talking about is even possible. As an industry though, once we get the messaging right, you are going to see more and more agile adoptions led from the C-suite, not in silly Dilbertesque caricatures, with informed intent around how to build organizations with a systems based perspective.

In most large organizations, bottom up is not an option without leadership acting from the top.

The post Some Thoughts on Agile Transformation in Big Companies appeared first on LeadingAgile.

Categories: Blogs

Practices, Principles and Approaches

NetObjectives - Tue, 11/04/2014 - 08:11
I write this just before delivering a Leading SAFe course. I was considering the need to go beyond the practices of any approach one teaches. When I use the word "approach" interpret it to mean "approach/framework/method" if you believe what you do is not an approach. I accept that when you start folks on a path you have to be somewhat prescriptive. All successful approaches have done this....

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Certified ScrumMaster Workshop in Kitchener-Waterloo—February 9-10

Notes from a Tool User - Mark Levison - Tue, 11/04/2014 - 00:49
Agile Pain Relief presents a two-day Certified ScrumMaster Workshop in Kitchener-Waterloo—February 9-10, taught by certified ScrumMaster Trainer Mark Levison.
Categories: Blogs

Isn‘t Kanban Just Common Sense?

TV Agile - Mon, 11/03/2014 - 18:22
Many problems we are trying to solve in software and product development are complex, with no obvious solution. As a result it is not possible or appropriate to simply define and follow best or good practice. Instead me must think in terms of heuristics to discover contextual solutions. Learn how you can use Kanban as […]
Categories: Blogs

Drive Business Transformation by Reenvisioning Your Operations

J.D. Meier's Blog - Mon, 11/03/2014 - 18:17

When you create your digital vision, you have a few places to start.

One place to start is by reenvisioning your customer experience.   Another place to start is by reenvisioning your operations.   And, a third place to start is by renvisioning your business model.

In this post, let’s take a look at reenvisioning your operations.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned from companies that are digital masters that created their digital visions and are driving business change.

Start with Reenvisioning Operations When Financial Performance is Tied to Your Supply Chain

If your financial performance is closely connected to the performance of your core operations and supply chain, then reenvisioning your operations can be a great place to start.

Via Leading Digital:

“Organizations whose fortunes are closely tied to the performance of their core operations and supply chains often start with reenvisioning their operations.”

Increase Process Visibility, Decision Making Speed, and Collaboration

There are many great business reasons to focus on improving your operations.   A few of the best include increasing process visibility, increasing speed of decision making, and improving collaboration across the board.

Via Leading Digital:

“The business drivers of operational visions include efficiency and the need to integrate disparate operations.  Executives may want to increase process visibility and decision making speed or to collaborate across silos.”

Proctor & Gamble Reenvisions Operational Excellence

Proctor and Gamble changed their game by focusing on operational excellence.  The key was to be able to manage the business in real time so they could keep up with their ever-changing world.

Via Leading Digital:

“For instance, in 2011, Proctor & Gamble put operational excellence at the center of its digital vision: 'Digitizing P&G will enable us to manage the business in real time and on a very demand-driven basis.  We'll be able to collaborate more effectively and efficiently, inside and outside the company.'  Other companies in industries from banking to manufacturing, have transformed themselves through similar operationally focused visions.”

Operational Visions are Key to Businesses that Sell to Other Businesses

If your business is a provider of products or services to other businesses, then your operational vision is especially important as it can have a ripple effect on what your customers do.

Via Leading Digital:

“Operational visions are especially useful for businesses that sell largely to other businesses.  When Codelco first launched its Codelco Digital initiative, the aim was to improve mining operations radically through automation and data integration.  As we described in chapter 3, Codelco continued to extend this vision to include new mining automation and integration operations-control capability.  Now, executives are envisioning radical new ways to redefine the mining process and possibly the industry itself.”

Operational Visions Can Change the Industry

When you change your operations, you can change the industry.

Via Leading Digital:

“The operational visions of some companies go beyond an internal perspective to consider how the company might change operations in its industry or even with its customers.“

Changes to Operations Can Enable Customers to Change Their Own Operations

When you improve your operations,  you can help others move up the solution stack.

Via Leading Digital:

“For example, aircraft manufacturer Boeing envisions how changes to its products may enable customers to change their own operations.  'Boeing believes the future of the aviation industry lie in 'the digital airline,' the company explained on its website. 'To succeed in the marketplace, airlines and their engineering and IT teams must take advantage of the increasing amount of data coming off of airplanes, using advanced analytics and airplane technology to take operational efficiency to the next level.' “

Get Information to the People Who Need it Most, When They Need It Most

One of the best things you can do when you improve operations is to put the information in the hands of the people that need it most, when they need it most, where they need it most.

Via Leading Digital:

“The manufacturer goes on to paint a clear picture of what a digital airline means in practice: 'The key to to the digital airline is delivering secure, detailed operational and maintenance information to the people who need it most, when they need it most.  That means that engineering will share data with IT, but also with the finance, accounting, operational and executive functions.' “

Better Operations Enables New Product Designs and Services

When you improve operations, you enable and empower business breakthroughs in all parts of the business.

Via Leading Digital:

“The vision will improve operations at Boeing's customers, but will also help Boeing's operations as the information from airplanes should help the company identify new ways to improve its product designs and services.  The day may also lead to new business models as Boeing uses the information to provide new services to customers.”

When you create your digital vision, while there are lots of places you could start, the key is to take an end-to-end view.

If your financial performance is tied to your core operations and your supply chain, and/or you are a provider of products and services to others, then consider starting your business transformation by reenvisioning your operations.

You Might Also Like

10 High-Value Activities in the Enterprise

Cloud Changes the Game from Deployment to Adoption

The Future of Jobs

Management Innovation is at the Top of the Innovation Stack

Reenvision Your Customer Experience

Categories: Blogs

Product Ownership as if You Meant It

Scrum Expert - Mon, 11/03/2014 - 18:15
Most companies don’t have empowered product owners in their Scrum projects. Instead they work with some kind of distributed product ownership. This talk analyzes why distributed product ownership is so common, what problems it produces and how to make it work. The key message of the session is that one size doesn’t fit all. For mission critical projects product ownership may be assumed by a top manager, for startup-like projects an empowered product owner in some kind of “sandbox” may be more appropriate and distributed product ownership is totally valid for ...
Categories: Communities

Lean India Summit, Bangalore, India, November 21-22 2014

Scrum Expert - Mon, 11/03/2014 - 17:52
The Lean India Summit is a two-day conference focused on Lean and Agile software development that takes place in Bangalore. Scrum and Agile are tied to the Lean thinking in a big way as concepts like remove waste come from the lean perspective. This event consists of a day of Kaizen Camp and another day filled with expert sessions. In the agenda of the Lean India Summit you can find topics like “Organizational Growth towards Lean Scrum by adopting agile practices”, “Building Agile Enterprise: From Productivity to Profitability”, “Being Lean and ...
Categories: Communities

The Definition of a Tech Lead - Mon, 11/03/2014 - 12:56

There are many names for leadership roles in software development such as Senior Developer, Architect, Technical Lead, Team Lead, and Engineering Manager. These are just a few. To me, the Technical Leader (Tech Lead) plays an unique and essential role that others cannot.

The Definition

The Short: A Tech Lead is a developer who is responsible for leading a development team.

Tech Lead

The Long: Leading a development team is no easy task. An effective Tech Lead establishes a technical vision with the development team and works with developers to turn it into reality. Along the way, a Tech Lead takes on traits that other roles may have, such as a Team Lead, Architect or Software Engineering Manager but they remain hands-on with code.

To make the most effective choices and to maintain trust and empathy with developers, a Tech Lead must code. In “The Geek’s Guide to Leading Teams” presentation, I talked about an ideal minimum time of about 30%.

Effective Tech Leads Code
An extract from the The Geek’s Guide to Leading Teams presentation

Not just a Team Lead

Early in my career, I worked on a team that had both a Tech Lead and a Team Lead. The Team Lead didn’t have much of a technical background and had a strong focus on the people side and tracking of tasks. They would have 1-to-1s with people on the team, and co-ordinate with outside stakeholders to schedule meetings that didn’t interrupt development time where possible.

The Team and Tech Lead

While the Team Lead focused on general team issues, the Tech Lead focused on technical matters that affected more than just one developer. They stepped in on heated technical debates, and worked with outside stakeholders to define technical options and agree on solutions for future streams of work. They wrote code with the other developers and sometimes called for development “huddles” to agree on a direction.

More hands-on than an Engineering Manager

You manage things, you lead people – Grace Hopper

Any reasonably-sized IT organisation has an Engineering Manager. They are responsible for more than one development, and have tasks that include:

  • Maintaining a productive working environment for development teams.
  • Acquiring appropriate budget for development to support business goals.
  • Representing the technology perspective on a management or board level.
  • Establishes and/or co-ordinates programmes of work (delivered through development).
  • Responsible for overall IT headcount.

Engineering Manager

Depending on the size of an organisation, an Engineering Manager may also be called a Chief Technical Officer (CTO) or Chief Information Officer (CIO) or Head of Software Development.

Although an Engineering Manager represents technology, they are often very far-removed from a development team and rarely code. In contrast, a Tech Lead sits with developers, very much focused on moving them towards their goal. They work to resolve technical disputes, and are watchful of technical decisions that have long-term consequences. A Tech Lead works closely with the Engineering Manager to build an ideal work environment.

A good Architect look likes a Tech Lead

The Architect role ensures overall application architecture suitably fits the business problem, for now and for the future. In some organisations, Architects work with the team to establish and validate their understanding of architecture. A suitable amount of standardisation helps productivity. Too much standardisation kills innovation.

Some organisations have the “Ivory Tower Architect” who swoops in to consult, standardise and document. They float from team-to-team, start new software projects, and rarely follow up to see the result of their initial architectural vision.

An effective Architect looks like a good Tech Lead. They establish a common understanding of what the team is aiming for, and make adjustments as the team learns more about the problem and the technology chosen to solve it.

What is a Tech lead again?

A successful Tech Lead takes on responsibilities that sit with roles such as the Team Lead, the Architect and the Engineering Manager. They bring a unique blend of leadership and management skills applied in a technical context with a team of developers. The Tech Lead steers a team towards a common technical vision, writing code at least 30% of the time.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Emergent Design - Sun, 11/02/2014 - 22:53
Then and now

In a recent email, Martin Alaimo asks:

There’s a very interesting discussion on the latin america agile community going on. It’s about the meaning of the Agile Manifesto Principle: “The best architectures, requirements, and designs emerge from self-organizing teams.”

What is currently under discussion is the meaning of “emerge”, basically, what does it mean that the “architecture emerge”.

So, I would like to reach up to you to share your impressions as a Manifesto signer. Here are two questions, but feel free to add whatever you feel is needed:

1) Back in 2001, at the time of signing the manifesto: what was the sense in which the word “emerge” was used in regards to the architectures?

2) After 13 years, is there anything you’d change/adapt/add in regards to “architecture” in the agile world?

I can’t speak about what everyone was thinking. I’m not sure what I was thinking. Here’s what I, and we, may have had in mind. Or maybe what I have in mind now.

Historically, the heavier approaches to software development have included a separation of architecture and design from “mere coding”. We felt that was far from ideal. Programming is the process of expressing design in some language. Just as our thoughts shape our words, our words shape our thoughts. The end of the sentence is conditioned not just by what we thought we wanted to say, but by how we begin to say it. And sometimes we go back and rewrite the beginning, because of what we find at the end.

The paragraph above is an example, because I didn’t go back to revise it. It’s an example of something that needs refactoring. It starts out being about software and turns into something about language and thought influencing each other. This part of the article might be better designed with the language bit first and then a segue into the software analogy. But I’m not going to do that, to show how a text can call out, or at least whisper, to be changed. That’s part of what we were concerned about.

However, where I thought I was really headed with that paragraph was to the people. In software, it’s the people. Maybe I’ll get there … but not yet.

We perceived, back at Snowbird, that the code needed to influence the design. It wasn’t a one-way street. No matter how much design we did on its own, as soon as we began to express it in code, the design needed to change. We expressed it as the code telling us what the design wanted to be. Very anthropomorphic. Very metaphorical. We knew that. Almost none of us really heard the code talking to us. (That one guy: You know who you are.)

These design discoveries continue to come, throughout the life of the project, if you stay open to them. To stay open to them, you have to keep the code alive: thus refactoring. However, to stay open to them, you also need strong designers in the room, listening, when the code speaks.

And voila! There are the people. I was sure they’d turn up. The people need to be self-organizing. And they need to have the ability, not just the right, to improve the design. They improve the design over time. It changes. It emerges.

If the program is to stay alive, design must change, it must emerge. If this is to happen, the team must do it. If the team is to do it, they must be organized to do it. The best way to organize is in response to the moment. To respond in the moment, you need to be in the moment.

A self-organizing team is the best way to keep the team in the moment, the best way to respond to the moment, the best way to improve the design in the moment it needs it.

The best results emerge from self-organizing teams.

Categories: Blogs

What Team Level Approaches Should Consider

NetObjectives - Sun, 11/02/2014 - 10:53
All models are wrong, some are useful - George Box In theory, theory and practice are the same. In practice, they are different. Einstein Paraphrasing Wittgenstein: He who understands things finally recognizes their propositions as senseless, when he has climbed out through them, on them, over them, he must so to speak, throw away the ladder, after he has climbed up on it-then he sees the world...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

10 talks in 2 weeks! Here are the slides.

Henrik Kniberg's blog - Sat, 11/01/2014 - 20:01

Wow, it’s been a crazy period. Sydney, Trondheim, Oslo, 10 talks in 2 weeks! Didn’t really plan to do that much, but one thing led to another. Fun, but exhausting!

Henrik keynote @ TDC

  • 4 internal talks at several large banks in Sydney
  • Keynote at Scrum Australia, Sydney. Topic: “Scaling agile @ Spotify” (slides)
  • Keynote at Trondheim Developer Conference. Topic: “Succeeding with Lean software development” (slides).
  • Talk at NTNU (Norwegian University of Science and Technology), Trondheim. Topic: “How do you know that your product works” (slides)
  • Keynote at Smidig 2014, Oslo. Topic: “Scaling agile @ Spotify” (slides) (video)
  • Lightning talk at Executive Workshop at Smidig 2014, Oslo. Topic: “Change” (slides).
  • Talk at Sintef, Oslo. Topic: “Lean from the Trenches” (slides).

Here’s a high-quality video recording of the Smidig 2014 keynote (on Spotify engineering culture). The conference organizers say it’s the highest-rated talk they’ve ever had! Cool :o)


Here’s a shorter version with much the same content, in the form of a two-part animated video series, for the impatient.

Categories: Blogs

Rant about Commitment – One of the Scrum Values

Learn more about our Scrum and Agile training sessions on

The voting for re-introducing the five values of Scrum into the Scrum Guide is heating up with some great discussion (debate?).  One person, Charles Bradley is providing some interesting arguments about why “commitment” should not be included or even changed to a different word.  I have posted a response.  I strongly believe that the word “commitment” is the right word.  Here’s the first paragraph of my response:

Hi Charles, although I appreciate your concerns about the word commitment, there is still huge support for adding the five values back to the Scrum Guide, including using that “bad” word. I would like to present to you an argument for the use of the word commitment by telling a story.


A long time ago I had a really good friend….


Check out all the discussion on the five values of Scrum and please comment or vote (or both!)

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!
Categories: Blogs

Is it SAFe to Scrum? A post by Em Campbell-Pretty

Agile Product Owner - Sat, 11/01/2014 - 17:03

It’s always interesting to see opinions on SAFe from leaders in the field. In this case, SPC Em Campbell-Pretty took Mike Cohn’s CSM class. You have to admit, that should be interesting, indeed. See her post here.

I’ll file this one under the Fun with Methods category.



Categories: Blogs

Critical factors for effective distributed teams

With distributed teams, it is very easy to develop an us vs them relationship.  There is a whole lot of informal interaction that occurs when we're co-located that don't happen when we're separated.  A lot of this random interaction might seem trivial and pointless but it all contributes to remind us that we're dealing with humans and not faceless entities.  This is essentially about propinquity.
Critical Factor #1: Increase the amount of informal interaction to humanise relationships
Some techniques I've seen that have been useful include:
  • Always-on video conferencing.  If there's too much background noise, mute sending on each side which allows you to un-mute to call out to the other side for ad-hoc communication.
  • Flying people to visit to and from each location.  This is especially useful at the start but also needs to be done regularly during the entire delivery.
  • Electronic collaboration tools like chat rooms, Yammer, etc.
Although, it's important to increase the humanising interactions, it's also important to reduce the amount of interactions required to do the actual work.  No matter what we do, it's harder to communicate across locations compared to the same location.
Critical Factor #2: Decrease the amount of communication across locations required for doing the work
Some techniques I've seen that have been useful include:
  • Separation of work across locations by self-contained capability, not by function.  This typically requires a loosely coupled architecture, for example microservices.
  • Integration contract tests.  A lot of ongoing communication is related to clarifying unclear expectations.  Integration contract tests are a way to be much more explicit and concrete about expectations as well as provide a trigger for when expectations are diverging thus requiring communication.
Co-location compensates for many team practices that would otherwise be ineffective.  Problems that seem small in a co-located context become very large when distributed.  Before you scale up a distributed setup, you should already be able to detect the types of problems you'll face from a co-located setup, but the problems will just seem very small.
Critical Factor #3: Sweat the mundane details.  Minor issues when co-located are major issues when distributed.
A particular mundane detail that I've seen that is critical is...
  • Keeping the communication technology working no matter what.  A common error is not forecasting expected demand in bandwidth to support video conferencing as the number of teams grow.
Categories: Blogs

R: Converting a named vector to a data frame

Mark Needham - Sat, 11/01/2014 - 01:47

I’ve been playing around with igraph’s page rank function to see who the most central nodes in the London NoSQL scene are and I wanted to put the result in a data frame to make the data easier to work with.

I started off with a data frame containing pairs of people and the number of events that they’d both RSVP’d ‘yes’ to:

> library(dplyr)
> data %>% arrange(desc(times)) %>% head(10) times
1  Amit Nandi Anish Mohammed    51
2  Amit Nandi Enzo Martoglio    49
3       louis          zheng    46
4       louis     Raja Kolli    45
5  Raja Kolli Enzo Martoglio    43
6  Amit Nandi     Raja Kolli    42
7       zheng Anish Mohammed    42
8  Raja Kolli          Rohit    41
9  Amit Nandi          zheng    40
10      louis          Rohit    40

I actually had ~ 900,000 such rows in the data frame:

> length(data[,1])
[1] 985664

I ran page rank over the data set like so:

g =, directed = F)
pr = page.rank(g)$vector

If we evaluate pr we can see the person’s name and their page rank:

> head(pr)
Ioanna Eirini          Mjay       Baktash      madhuban    Karl Prior   Keith Bolam 
    0.0002190     0.0001206     0.0001524     0.0008819     0.0001240     0.0005702

I initially tried to convert this to a data frame with the following code…

> head(data.frame(pr))
Ioanna Eirini 0.0002190
Mjay          0.0001206
Baktash       0.0001524
madhuban      0.0008819
Karl Prior    0.0001240
Keith Bolam   0.0005702

…which unfortunately didn’t create a column for the person’s name.

> colnames(data.frame(pr))
[1] "pr"

Nicole pointed out that I actually had a named vector and would need to explicitly extract the names from that vector into the data frame. I ended up with this:

> prDf = data.frame(name = names(pr), rank = pr)
> head(prDf)
                       name      rank
Ioanna Eirini Ioanna Eirini 0.0002190
Mjay                   Mjay 0.0001206
Baktash             Baktash 0.0001524
madhuban           madhuban 0.0008819
Karl Prior       Karl Prior 0.0001240
Keith Bolam     Keith Bolam 0.0005702

We can now sort the data frame to find the most central people on the NoSQL London scene based on meetup attendance:

> data.frame(prDf) %>%
+   arrange(desc(pr)) %>%
+   head(10)
             name     rank
1           louis 0.001708
2       Kannappan 0.001657
3           zheng 0.001514
4    Peter Morgan 0.001492
5      Ricki Long 0.001437
6      Raja Kolli 0.001416
7      Amit Nandi 0.001411
8  Enzo Martoglio 0.001396
9           Chris 0.001327
10          Rohit 0.001305
Categories: Blogs

iOS localization tricks for Storyboard and NIB files

Xebia Blog - Sat, 11/01/2014 - 00:36

Localization in iOS from Interface Builder designed UI has never been without any problems. The right way of doing localization is by having multiple Strings files. Duplicating Nib or Storyboard files and then changing the language is not an acceptable method. Luckily Xcode 5 has improved this for Storyboards by introducing Base Localization, but I've personally come across several situations where this didn't work at all or when it seemed buggy. Also Nib (Xib) files without ViewController don't support it.

In this post I'll show a couple of tricks that can help with the Localization of Storyboard and Nib files.

Localized subclasses

When you use this method, you create specialized subclasses of view classes that handle the localization in the awakeFromNib() method. This method is called for each view that is loaded from a Storyboard or Nib and all properties that you've set in Interface Builder will be set already.

For UILabels, this means getting the text property, localizing it and setting the text property again.

Using Swift, you can create a single file (e.g. LocalizationView.swift) in your project and put all your subclasses there. Then add the following code for the UILabel subclass:

class LocalizedLabel : UILabel {
    override func awakeFromNib() {
        if let text = text {
            self.text = NSLocalizedString(text, comment: "")

Now you can drag a label onto your Storyboard and fill in the text in your base language as you would normally. Then change the Class to LocalizedLabel and it will get the actual label from you Localizable.strings file.

Screen Shot 2014-10-31 at 22.45.46

Screen Shot 2014-10-31 at 22.46.56

No need to make any outlets or write any code to change it!

You can do something similar for UIButtons, even though they don't have a single property for the text on a button.

class LocalizedButton : UIButton {
    override func awakeFromNib() {
        for state in [UIControlState.Normal, UIControlState.Highlighted, UIControlState.Selected, UIControlState.Disabled] {
            if let title = titleForState(state) {
                setTitle(NSLocalizedString(title, comment: ""), forState: state)

This will even allow you to set different labels for the different states like Normal and Highlighted.

User Defined Runtime Attributes

Another way is to use the User Defined Runtime Attributes. This method requires slightly more work, but has two small advantages:

  1. You don't need to use subclasses. This is nice when you already use another custom subclass for your labels, buttons and other view classes.
  2. Your keys in the Strings file and texts that show up in the Storyboard don't need to be the same. This works well when you use localization keys such as myCoolTableViewController.header.subtitle. It doesn't look very nice to see those everywhere in your Interface Builder labels and buttons.

So how does this work? Instead of creating a subclass, you instead add a computed property to an existing view class. For UILabels you use the following code:

extension UILabel {

    var localizedText: String {
        set (key) {
            text = NSLocalizedString(key, comment: "")
        get {
            return text!


Now you can add a User Defined Runtime Attribute with the key localizedText to your UILabel and have the Localization key as its value.

Screen Shot 2014-10-31 at 23.05.18

Screen Shot 2014-10-31 at 23.06.16

Also here if you want to make this work for buttons, it becomes slightly more complicated. You will have to add a property for each state that needs a label.

extension UIButton {
    var localizedTitleForNormal: String {
        set (key) {
            setTitle(NSLocalizedString(key, comment: ""), forState: .Normal)
        get {
            return titleForState(.Normal)!

    var localizedTitleForHighlighted: String {
        set (key) {
            setTitle(NSLocalizedString(key, comment: ""), forState: .Highlighted)
        get {
            return titleForState(.Highlighted)!

Always try and pick the best solution for your problem. Use Storyboard Base Localization if that works well for you. If it doesn't, use the approach with subclasses if you don't need to use another subclass and if you don't care about using your base location strings as localization keys. Else, use the last approach with User Defined Runtime Attributes.

Categories: Companies

Move Fast, with Stability

Rally Agile Blog - Fri, 10/31/2014 - 14:00

By now, you've probably heard about the impending breakup of HP into two separate companies. Some are calling the division of the 75-year-old business a “watershed moment for one of tech's most iconic companies."

Here’s something we thought was worth calling out: Interviewed about the breakup, HP CEO Meg Whitman said this:

“Nimbleness and speed are going to be an important part of the future … By separating into two companies with quite distinct markets, with quite distinct customers, we’ll be able to move faster to take advantage of the changing customer needs and accelerating our product and innovation road map.”

Get to market faster. Grow faster. Respond faster to customer demand. Move faster than the competition. These days speed isn’t just a priority; it’s a necessity. When it comes to building software, improving cycle time significantly impacts your bottom line. Speed helps you monetize incremental value and get to revenue sooner. It taps the voice of the customer early and often, giving you confidence that you’re “building the right thing.”

With software eating the world, and small companies eating the lunch of large companies, you have to get to the table fast or risk not getting a seat at the table at all. Nimbleness and speed are important attributes for any company, but they’re not particularly associated with large enterprises. As Whitman points out, this doesn’t mean enterprises are exempt from the need for speed -- but they are more likely to be unprepared for it:

“The consumer space moves like lightning speed … What has been surprising is how fast the enterprise space is moving.”

Balancing Speed and Stability

The Facebook mantra of “Move fast and break things” became a famous example of how many fast-growing companies value speed over risk … until earlier this year when Facebook, now a large and public company, changed its infamous motto to “Move fast with stability.” In fact Facebook CEO Mark Zuckerberg, who once accused larger companies of moving slowly because they were more afraid of making mistakes than of missing opportunities, has lately been singing a new tune:

“Now, instead of just throwing something out there, we’re making sure that we’re getting it right first.”

Speed is at the crux of execution agility, as we discussed last week. But speed alone doesn’t equate to winning the market. Zuckerberg’s point is an important one: you don’t want to move so fast that you’re deploying bad code and incurring technical debt, or building a strategy around features no one wants. You need confidence that you’re building the right things, and building them right.

Start with Agile

If you’re not already using Agile methodologies, there’s a wealth of evidence that it’s time for you to switch. Research from an independent study found that companies using Agile bring products to market 37% faster, and see 25% higher productivity than non-Agile companies -- with no increase in defects. More research on Agile firms found that they grow revenue 37% faster, and generate 30% higher profits. Forrester says that 40% of development is now Agile, and Computer Economics estimates that 83% of businesses have future plans to implement Agile (an increase from 59% last year.)

Then Improve Your Agile Performance

If you’re already using Agile practices, then you want to focus on how to improve your Agile performance -- so you can move faster without sacrificing quality or efficiency. Agile and Lean are built on a foundation of continuous improvement: You need to inspect, learn from, and adapt your performance to keep improving. To do this, you need data on your own performance.

We recognize the value of performance improvements, which is why we’ve culled the data of 50,000 Agile teams and 160,000 projects to identify metrics across key performance dimensions like Productivity, Predictability, Quality, and Responsiveness. These metrics provide evidence-based insights for benchmarking, measuring, and adjusting your performance with real-time feedback and improvement recommendations. Our research has also uncovered some dramatic findings -- like how teams can double productivity, cut time to market in half, and improve quality by 250%. We think the data make a pretty compelling case, but maybe you'd rather take someone else's word for it.

Here’s Michael Santoro, Director, GVS Global Business Partnership Team at Tata Communications, on the value they saw from Agile performance metrics:

“With Rally Insights, we uncovered the performance costs of unstable teams … and are seeing 30–50% improvements in both cost and delivery duration compared to similar waterfall projects.”

And here’s GE Capital Americas CIO of business intelligence, Kelly Shen, explaining why Agile trumps traditional approaches and analytics:

“Advanced analytics is best suited for this because you’re dealing with a level of ambiguity … If you go through a traditional software development cycle, you see the data for the first time after you build something. With agile, you can start seeing things as you develop the prototype -- usually days in ...The only way to know the value of analytics is to get it in front of end users as fast as possible … Fail fast, learn early, change strategy when it’s not working.”

How's your company doing on the nimbleness and speed front? Learn more about how to measure and improve your performance. Get a copy of the Business Agility Survival Guide.

Rally Software
Categories: Companies

Partnerships & Possibilities, Episode 3, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/31/2014 - 13:51

Partnerships & Possibilities: A Podcast on Leadership in Organizations

Photo Credit: Victoria Nevland via Compfight cc

[introduction] How do things get done on a self-organizing team? It seems like nobody is directing the work…

[3:55] As a manager, knowing what leadership roles you need covered on a team would help to populate your teams.

[5:30] Look for T-shaped team members, and “Pi-shaped” team members, for bench strength.

[9:30] Knowing these roles could help you charter your team.

[10:10] Pioneer and Instructor roles are the early adopters of new ideas.

[11:40] Influencer and Follower roles.

[13:25] Commentator, Advocate, and Coordinator roles.

[16:35] CAUTION: All these roles are not job titles – they are roles that some or all team members may fluidly move in and out of from time to time.

[19:50] The Promoter, Mentor, and Peacemaker roles.

[23:00] The Critic, Gatekeeper, Dissenter.

[26:20] The Reviewer and the Monitor.

Shared Leadership Roles PDF

Categories: Blogs

hdiutil: could not access / create failed – Operation canceled

Mark Needham - Fri, 10/31/2014 - 11:45

Earlier in the year I wrote a blog post showing how to build a Mac OS X DMG file for a Java application and I recently revisited this script to update it to a new version and ran into a frustrating error message.

I tried to run the following command to create a new DMG file from a source folder…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

…but was met with the following error message:

...could not access /Volumes/DemoBench/ - Operation canceled
hdiutil: create failed - Operation canceled

I was initially a bit stumped and thought maybe the flags to hdiutil had changed but a quick look at the man page suggested that wasn’t the issue.

I decided to go back to my pre command line approach for creating a DMG – DiskUtility – and see if I could create it that way. This helped reveal the actual problem:

2014 10 31 09 42 20

I increased the volume size to 150 MB…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

and all was well:

created: /Users/markneedham/projects/neo-technology/quality-tasks/park-bench/database-agent-desktop/target/pack.temp.dmg

And this post will serve as documentation to stop it catching me out next time!

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.