Announcement: Certified Scaled Agile Framework Program Consultant (SPC) – Mishkin Berteig and Travis Birch
I’m happy and proud to announce that both myself and Travis Birch have passed our SAFe SPC test after our training in early October. This means that Berteig Consulting will start offering a number of SAFe related training sessions both publicly (on World Mindware) and as in-house. We are also experienced in large scale applications of Agile and SAFe is a great framework to have in our toolkit along with our Real Agility Program. If you are considering using Agile at scale or if you are having trouble with making Agile at scale work effectively, I hope you will contact us.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!
Since Rally announced our support for SAFe™ 3.0 in July, we've been hard at work making sure our support for the latest Scaled Agile Framework® is all-encompassing.
We know that scaling agility takes more than a product. In Dean’s words, “a fool with a tool is still a fool.” To benefit from agility at scale, we need to learn a new way to do portfolio and program management. Training and education are key, especially at these levels. Expertise from those who’ve helped others adopt SAFe can be a huge time-saver. The focus that SAFe 3.0 brings to the portfolio level only emphasizes the need to have good scaled Agile practices in place.
As a whole solution provider, Rally’s consulting, platform, and expertise are key to making you successful at scale.Rally Program Launch with SAFe
Rally Program Launch with SAFe provides the right coaching, training, and tooling to establish Agile release trains quickly and effectively, so you can coordinate teams of teams to deliver value to the market in as little as three months. With one of the largest and most experienced stables of Agile coaches and SAFe SPCs (recognized by Dean himself), Rally can get you started in time for your next planning event and help you ensure a successful outcome.Rally SAFe Training
Rally has made major updates to our Agile Portfolio Management class, the only class in the industry that teaches you the critical mindset shift necessary for modern portfolio management. The class covers SAFe 3.0 portfolio concepts, as well skills like investing in themes rather than projects and steering work rather than resources. We’re offering two Agile Portfolio Management classes before the end of the year (London, Nov 13-14 and Boulder, Dec 9-10): join us and be ready for Q1. Don’t forget our Leading SAFe class, which provides training for the Lean-Agile Leader role -- now recognized on the “Big Picture” as a key role in driving Agile and lean concepts adoption.SAFe Support in the Rally Platform
We’ve also enhanced Rally Unlimited Edition with features that directly support SAFe 3.0:
- The Release Planning Board supports the development planning cadence (“Develop on Cadence”) and allows users to create realistic release plans that consider feature size, cost of delay, and development capacity. Each “release” tracks a Program Increment (PI.)
- Portfolio Kanban provides value stream tracking with all the great user experience you expect, such as state-specific policies and customized card content.
- Lean portfolio metrics with the Rally Insights™ Time in Process (cycle time,) Productivity, and Predictability charts give you important feedback on your performance.
- ART metrics, such as the Release Burnup with projection line (get it in our Rally GitHub Community,) let you see iteration and release progress (SAFe Release Train level metrics.)
- Milestones (soon to launch in beta) support the development delivery cadence (“Deliver on Demand”) decoupled from the development planning cadence. Milestones, shown on the Portfolio Timeline below, provide the ART participants with a “Release Feature Progress Report” to help steer work towards business goals.
SAFe at RallyON Europe
To our European friends attending RallyON! Europe next week in London, don’t miss the opportunity to boost your scaled Agile expertise by attending one of our post-conference classes, 13-14 November. For a complete list of upcoming classes, visit our Agile University calendar.
We hope to see you on the SAFe train in 2015!Rally Software
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 […]
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?
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.
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.
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.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
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
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.
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%.
Not just a Team Lead
An extract from the The Geek’s Guide to Leading Teams presentation
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.
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.
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.
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.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
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!
- 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.
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!
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.
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.
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.
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.
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) p.name other.name 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])  985664
I ran page rank over the data set like so:
g = graph.data.frame(data, 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)) 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))  "pr"
> 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