Search This Blog

Sunday, November 29, 2015

Catching up

Wow. So much has been going on and I've been so many places it's hard to keep up with myself. Here is a quick recap.

In late August I traveled to the states to see my family and work with some of my colleagues in the Phoenix office for a couple weeks. I planned to take time off while there but ended up extending the trip by a week and working almost the entire time. This turned out to be a good thing for work but not for me or my family.

I returned to Manila mid-September and, while trying to fit in some day tours of the Philippines, starting planning a trip to India to meet and assess the teams there to see what they might need to help them in the transformation. One team is in Kochi, on the southwestern coast of India and the other in Bangalore.

My colleague and I planned a couple days to sightsee while we were there, but it really wasn't enough.

India has a beauty in the culture and architecture that requires time to savor. Luckily, it looks like we'll be headed back there early next year.

In the meantime, I started to take scuba diving lessons with an eye toward certification.

I have seen and climbed Mt Tabaro, which is located in Taal Lake--it's actually an island in the largest lake in the world on an island, and has it's own island--snorkeled and dived in Anilao, Batangas; and walked on the shores of the Arabian Sea and in a 1000 year old temple.

We were blessed by the monks in a temple in India and learned about the gods who watch over the people of India and will watch over us too. They're not picky; they offer protection to all.

I'll try to get back on track with blogging, but don't be surprised if my activities keep me so busy I can offer little but photo uploads!

Randomness

There is so much to see and do, depending where you go, in the Philippines that it's hard to share it all, but here are some random flora and fauna, market sites, and more.























Tuesday, September 8, 2015

Introducing Mob programming: The best team technique you've (probably) never heard of

Editors Note: I am unable to blog as I am traveling and my schedule has blown up, but I do have stuff to share; here is an article I read that I thought was pretty interesting. I like the concept and the name. This is reprinted in full from Infoworld.

Introducing Mob programming: The best team technique you've (probably) never heard of
 Mob Programming extends Pair approach for productivity, quality gains in software development


For software design and development (and many, many other tasks), productivity is always a high priority -- and in pursuit of this is a seemingly never-ending supply of new methods, from Kaizen "continuous improvement" to newer ones like Agile and Lean.

One of the newest approaches is Mob Programming, an outgrowth of Pair programming, an Agile technique where two programmers work together, sharing a single computer and taking turns at the keyboard.

"We discovered the Mob Programming approach from what we had been doing as a learning technique," recalls Woody Zuill, Senior Consultant with Agile development firm Industrial Logic, in a phone interview. "We were using a Coding Dojo style where everyone works together at a single computer to practice solving a programming problem. The style was based on Llewellyn Falco's 'strong pairing' Driver/Navigator model of the pair programming method."

Mob Programming, says Zuill, "is basically an expansion of that approach: working in a group, with one person at the keyboard to 'drive' -- enter and edit the code -- and everyone else working together as the 'navigator,' 'guiding' what goes into the keyboard. The passing around of the keyboard was based on the principle, 'If I have an idea, I have to hand the keyboard to somebody else, so I can explain it, draw it on the whiteboard, and discuss it before it is keyed into the computer.'"

Working as a team, it's a lot easier to see patterns and to act on them.-- Woody Zuill
And after a few hours of working as a Mob, says Zuill, "We realized that it was working so well we wanted to keep on doing it for the rest of the day. And at the end of the day, we decided to keep working this way the following day. That was four years ago." Zuill eventually wrote write this up in a blog post titled "Mob Programming: A Whole Team Approach."

The software project that Zuill and his co-workers did their first Mobbing on was "very complex, requiring input from all the developers." So, says Zuill, "We thought that meant this approach was best suited for solving complex problems quickly. But once we got good at Mobbing, we realized that it also was useful for smaller, simpler problems, because you can often find a way to abstract or automate tasks that are easy or repetitive, like cleaning up items in a database. Working as a team, it's a lot easier to see patterns and to act on them."

Bluefruit mobs up

In November 2014, Bluefruit Software, an embedded software development firm, which had already been using Pair programming, decided to give Mobbing a try, based on the advice of Nancy Van Schooenderwoert, President of Lean-Agile Partners, Inc., a technology training and consulting firm.

The place that Mobbing has helped the most is merging code when people have been working alone and in pairs.-- Matthew Dodkins

"We were adding more engineers, and Nancy, who we'd been working with for several years, suggested Mob Programming as one way to mature technical leads faster," recalls Bluefruit's owner & CEO Paul Massey. "While Mobbing's having the whole team around one keyboard sounded even less efficient than Pairing, we decided to give it a go."

And it worked.

"The place that Mobbing has helped the most is merging code when people have been working alone and in pairs," says Matthew Dodkins, a software architect at Bluefruit. "In a day spent using traditional collaboration, you would have to first spend time agreeing on tasks, common goals, deciding who's doing what... and then going away to do that, write code, and come back and merge it, resolve problems."

By bringing everyone into the same room, "we try to merge frequently, and try to do almost continuous integration," says Dodkins. "A lot of code gets merged all the time. For a big code project, we try to do it all the time. When developers are programming individually, we can be 'lost in code' for up to a week. None of our mob merges last more than a day, as opposed to working for a week and only then learning you're off -- meaning several peoples' code doesn't fit together."

"We find Mobbing good for solving complex problems, and dealing with merges of code by multiple people," says Dodkins. "You get the power of everyone's knowledge on the problem. It's also a positive learning and social experience -- all the team members can learn about the project, and can contribute to difficult problems that are blocking the project."

So far, Bluefruit has used Mob techniques "on a bit of everything," reports Massey. "We've used it on projects for our blue chip clients like Electric Bike and Home Information Systems, where we may have a dozen engineers organized into multiple teams, usually with a maximum of six to seven per team. And we have a team of six, with maybe only one or two engineers, on a number of smaller programs for start-up clients -- this team may only all get together one morning per week."

The productivity payoff

Mobbing may sound counterproductive in terms of the use of developers’ time, but consider that “most organizations have frequent meetings with six or more people,” Zuill points out. "Think of these as working meetings rather than information-sharing ones. Software development isn't about being at a keyboard -- that's just how we get the work into the computer. But the work is thinking, and translating ideas into code."

Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want.-- Nancy Van Schooenderwoert

"If you measure by features or other classic development productivity metrics, Mobbing looks like it's achieving only 75 to 85 percent of individual or Pair output for, say, a team of six or seven working for a week," acknowledges Massey. "However, there's more to productivity than that. In the course of that programming, everyone has contributed their knowledge, so there's no need for training at the end -- nor need to merge. And merging is the most difficult task -- you have to understand the code you are merging. Individual work may have unpredictable problems, or need work to fit together."

"Mob Programming can feel slower, but the payoff is avoiding bugs, and getting the results that you want," says Lean-Agile's Van Schooenderwoert. And mobbing can be contagious (in a good way, of course). "If you deliver code to a customer, you may get them into mobbing as a way to review the code with them."

Mobbing is catching on

Mobbing is still in its early growth phase, but it's catching on quickly, says Industrial Logic’s Zuill: "A year ago I did a conference talk in Sweden about Mob Programming -- and this past week, I saw listings for two sessions in Sweden from teams talking about how they had gone about it. In 2013, I gave a talk on Mob Programming in Stockholm at Ericsson, and when I gave another talk there the next year, three other groups did presentations on how they were using Mob Programming. And I know of at least two or three dozen companies doing a substantial amount of Mob Programming."

And Mobbing isn't just for software development, notes Simon Clements-Hawes, an embedded systems tester at Bluefruit. "You can use Mobbing for training, education and other tasks. I've used it for educating, and for project and task completion."

Similarly, Zuill notes, "I've talked with people who aren't involved in programming, like project management groups, real estate managers, and finance companies who are using the Mob method. Mobbing is about working together on knowledge-based or thinking-intensive tasks." 

How to get started with Mobbing

"Getting started with mobbing is very simple," says Zuill. “I and others offer workshops on this, but Mobbing is an easy enough concept that you can experiment with it simply from watching online videos."

Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. -- Paul Massey

"There are a few simple guidelines, but the core is 'learning to work well together,'" advises Zuill. "You need a few mechanisms to share information, which is why the driver/navigator model of any idea going through somebody else's hands is important -- the people trying to solve the problem have to explain it to somebody else. This enforces clarity of thinking, versus somebody trying to unravel intent from code. And we want the code to express that intent -- that's about the quality."

Mobbing has two important real-world requirements: a room with a large enough space, and a projector or other large display to allow everybody in the room to see the code on the "driver's" screen. (A blackboard or whiteboard wouldn't hurt, either.)

While Pairing and Mobbing are usually done live, "we have experimented with Pairing remotely, as long as you have good communications," notes Bluefruit’s Massey. And, adds Lean-Agile's Van Schooenderwoert, "remote Mobbing and Pairing is easier to do if the people have already worked together."

"Agile is all about feedback loops. Mobbing is an extension of it," says Bluefruit's Dodkins. "And getting people together in a room is more collaborative. You can look at each other and gesture and express things better than online."

"Knowing we wanted to do mobbing influenced the layout for our new office," says Massey. "We made sure we had a space for teams to spontaneously mob."

"It was helpful to be shown the ropes, but Mobbing is pretty straightforward," says Massey. "Mob Programming is one of the least complicated things to pick up. I suspect that in some of the places that aren't adopting it, it may be due to the culture. This is the most self-propelled practice I've seen. Within a few weeks after training, we were using it successfully."

No silver bullet

Mobbing can't be the only tool in your arsenal, of course, and it isn't a replacement for solo activity. "We don't do this exclusively -- maybe only about a tenth of our time is spent 'mobbing,'" says Bluefruit's Dodkins.

"As with any practice, too much of one thing can be bad," adds Bluefruit's Massey. "For us, the Agile process is a set of principles, and Mob Programming is another tool in the toolkit, along with Pair programming, Test-Driven Development, Behavioral-Driven Development, and a dozen or so others."

"One drawback of mobbing is that while you get the benefit of all people's brains in the room you still need someone to review the code -- which should be somebody who's not in the room," says Dodkins. "If you aren't reviewing your code, good luck -- all code needs to be reviewed."
"Also," stresses Zuill, "I like Mob programming and feel it's good for people to learn it -- but more importantly I feel teams should work hard to figure out what works well for themselves. To figure out their own process by frequently reflecting, tuning and adjusting."

And, says Zuill, there's an unexpected social benefit to Mobbing: "We have found at our workplaces that, by working this way, everybody on the way feels more fulfilled in their lives. We work as a team all day long, and we are uplifting each other and helping each other have a better life. We didn't expect that. And I see this at many places where Mob Programming is being done."

Resources

·        Read more about Mob Programming at MobProgramming.org.
·        Learn about Mob Programming workshops by Industrial Logic
·        Want to see Mobbing in action, watch the time-lapse video below of a day of Mob Programming.


Sunday, August 9, 2015

Who is this Fibonacci guy?

As an Agile Coach, I want to help teams new to Agile understand how to use Story Points to estimate their work so they can establish their velocity.

According to Wikipedia*, Leonardo Bonacci was an Italian mathematician, considered "the most talented Western mathematician of the Middle Ages." He introduced to Europe the Hindu-Arabic numeral system primarily through his composition of 1202, Liber Abaci (Book of Calculation). 

Liber Abaci posed, and solved, a problem involving the growth of a population for rabbits based on idealized assumptions. 

(Ed note: Wikipedia does not mention why this was a problem to be solved; we are left to surmise.)

The solution, generation by generation, was a sequence of numbers which came to be known as the Fibonacci numbers. The number sequence was known to Indian mathematicians as early as the 6th century, but was not previously known in Europe.

In the Fibonacci sequence, each number is the sum of the previous two numbers. Fibonacci began the sequence not with 0, 1, 1, 2 as modern mathematicians do, but with 1,1,2.

Because it offers a unique opportunity to compare by relative size, this series is commonly used as story points in the Agile world.

Story points are an arbitrary unit of measurement, unique to each team, used to estimate the relative size of a story. We could use estimates like small, medium and large to estimate stories relative to one another--and many teams do--but the numbers provide a way to measure how much work we can get done in a specific time period.

Here's how it works; teams select a story and discuss it to understand the work that must be done. Then they collectively assign story points to it based on the complexity of effort required to complete the story. They do this for all the stories they have in their sprint backlog; they compare stories to each other to find their relative size. 

Eventually the sum of the story points becomes the target velocity for that sprint. Say a team plans to work on eight stories that total 24 story points; when the sprint ends, they accept story points for the work completed and the resulting number is the team velocity. 

When the team plans the next sprint they use this number as a target for planning. If they completed 24 story points worth of work in the last sprint, they should target 24 +/- 2-5 story points in the next sprint, depending on their maturity and capacity. Eventually they can take the average velocity from several sprints to use as their guide.

There are different ways to assign story points; I coach teams to use planning poker because I like to steer them toward consensus in estimating. Consensus is one of those things that will move a team toward true collaboration rather than being a group of people doing some work at the same time.

In my experience, especially for teams new to Agile, a group approaches consensus much quicker using poker planning cards, as it helps to prevent one team member deciding for all or influencing the rest of the group. Poker planning also helps them get past the initial I'm guessing stage, because the different estimates spark the conversation the team needs to have that results in a shared understanding of the work and a shared estimate.

I am asked often why we don't estimate stories using time--how long will it take to complete a story in hours; and a related question, why don't we tie hours to story points.

There is a very good reason why we don't do this and Mike Cohn explains it with an interesting example. But the bottom line is different people have different skill sets and experience, and what will take one person 1-2 hours could take another 2-3 times that.

There is no right or wrong number in estimating and every team will have different estimates for stories, even those that may be similar in effort, because it is relative to the skill sets and experience on each team. 

I have found that teams may start out not really understanding what they're doing or how it works but eventually they grasp the abstract concept of story pointing and establish a velocity which they then use to understand how much work they can take on in a sprint. It becomes a good jumping off point for them to continually inspect and adapt their practices; for example, if we automate testing can we get more stories done in a sprint? 

I usually provide poker planning cards (similar to those in the picture above) for the teams I coach, but getting something shipped to us here in the Philippines can be prohibitively expensive. Lucky for my teams, I was raised with a necessity is the mother of invention attitude so I often suggest to teams that they figure out a way to create their own cards. This varies from numbers written on post its or index cards to teams creating their own sets of cards--as seen here--to teams using apps on their phones.

The good news is that if I can get teams to perform the exercise for one or two sprints, they usually reach the point where they understand the sizing within their team, establish their velocity, and start looking for opportunities to continually improve--which is where we want them--rather than spending time debating with one another what story points mean or whether they should be tied to time.

*Information borrowed wholesale and paraphrased from the information on the Wikipedia site.