Skip to content

Companies

Rally’s Colorado Crew Pushes Pedal Power

Rally Agile Blog - Tue, 07/01/2014 - 18:54

In Boulder, Bike To Work Day (BTWD) is a big deal. At Rally, it’s HUGE. This year, as in years past, we went all-out and we played to win. Here are some highlights.

Supporting Bike-crazy Boulder.

Rally is a proud sponsor of Boulder Walk and Bike Month. Our donation from the Rally For Impact Foundation supports Community Cycles, which organizes a dizzying array of bike-related happenings throughout June. It’s so exciting to see our logo alongside those of so many other local businesses on the BTWD posters around town.

Best in Class -- Again!

For the sixth time in seven years, we placed at the top of our class in the Denver metro area Business Challenge. This year, with 300+ employees in Boulder and Denver, we got bumped up to Class D. But we still snagged first place thanks to our effort index of 5.49, with more than 140 out of 330 employees participating -- an impressive 43 percent! We celebrated with a company-provided lunch for cyclists at our new LoDo Denver office, right across from Union Station, and on the patio at our Boulder headquarters.

Pedal Power.

Throughout June, Boulder and Denver employees who biked and walked to work recorded their number of commutes and mileage each week. Our collective total: 4,407 miles! That’s 86 miles farther than the cycling distance from San Francisco to Washington, D.C. 

Spinning for a Cause.

We wanted to cycle with purpose, so we tallied $2 per person, per commute, and donated the total for each week to a nonprofit organization focused on a biking-related cause. The more people who biked, the more the Rally For Impact Foundation donated. All in all, we gave $1,188 to four nonprofits -- each representing a different geography:

Prizes for Participating.

Each week in June we held a (virtual) raffle to give away three $50 gift cards to employees (who earned tickets into the drawing with every walk or bike commute.) In addition, we gave $100 gift cards to the cyclist with the top mileage and most commutes for the month. Chris Driscol was our top mileage winner with 309 miles, and Cameron Holck won the contest for most commutes by cycling 17 out of 18 work days. Both winners selected Boulder Food Rescue to receive $250 donations in their names from the Rally For Impact Foundation.

Going with the Flow.

Our employee biking community used Rally’s team collaboration tool, Flowdock, to stay in touch about all our Walk and Bike Month events -- especially to track how we were doing in the Business Challenge, who was leading the top mileage and commute days categories, and of course, lunchtime rides.

Thanks to everyone who participated, thanks to Rally for supporting the cause, and congratulations to all our raffle and grand prize winners. We can’t wait to do it all again next year!

Angela Tucci, chief marketing officer, and Christine Hudson, solution manager, decked out in Rally jerseys for Bike To Work Day, rode 38 and 32 miles round trip, respectively.

Bike commuters (including me in the green shirt and blue helmet) ready to head home on Bike To Work Day.

 

More than 100 bikes overflowed Rally’s Boulder headquarters on Bike to Work Day. With plenty of regular bike commuters, Rally offers storage areas and mounted racks inside and outside of the building.

Geri Mitchell-Brown
Categories: Companies

How It Works: Kanban+Timeline

TargetProcess - Edge of Chaos Blog - Fri, 06/27/2014 - 16:09

If you’re using Kanban board as a process tool in software development, you must know that Kanban is mainly about letting the work flow through the production states.

Pull some work from backlog, get it through the pipeline and on it goes.

Kanban is great, but it desperately lacks one thing which matters a lot in this world plagued by time constraints. This thing is called a sense of time. If a team does some cross-project work, as they pull smaller items from a support requests backlog, they will likely want to be informed not only of a current state of a work item. They will want to know when it is safe to assume that this work item will be done, or passed over to another department, etc. Trying a workaround to include this sense of time to a physical Kanban board on a wall might be a cumbersome task. Take a look:

Kanban with time

This board has a mention of a milestone, Nov 9. The stickers are to-do items. This workaround just informs of a fixed milestone, and doesn’t take the production dynamics into account. There’s no way to give a forecast from this board, if the team will complete whatever their work is by November 9, judging by the pace with which they progress. Not to mention that there’s no way to see at which pace are they progressing. There are some Kanban reports that can help predict that, but they will not be available in a whiteboard, obviously. This might work for this team, but some other hypothetical team will want their Kanban board tailored to their time-sensitive objectives in a different way. And they would need to sweat and invent specific workarounds, if they need more than just a date written on a board.

We’ve always wanted to help our brothers sweat less at work :) .. and we’ve been well aware of this need, that timelines should be somehow intertwined with Kanban boards. The project management tool that we develop supports Kanban along with other dev processes, and our on-going goal is to make the tool still more convenient. That’s why we’ve implemented timelines that can now be used in combination with a digital Kanban board.  We used to have a paper timeline on the wall, too, but this visual roadmap is more of a thing that creates the spirit of common purpose, than a hands-on tool. The Kanban+timelines combination can be used to see how teams are doing with their work, and in what time they expect to complete it. That’s how this Kanban+timeline board might look (click to enlarge):

Timelines tracking for many projects

There are two projects on this board, and there’s a backlog for each of them. Alternatively, there can be a shared backlog (our tool supports that as well). What goes next are work items laid over a stretch of time. Where the strips end is the current forecast for “Done”.  The timeline can accompany the traditional Open-In Progress states on a Kanban board as well, if that’s what someone needs. Again, no sweat here, one can quickly set up a custom timeline+Kanban combination in our tool.

Having a timeline available as another option on top, or instead of a Kanban board, helps make sense of what’s going on with the projects in less time, pun intended. Besides, timelines keep the sense of time always present with a team (which they might be missing if they only look at a plain Kanban board). It surely is less hassle to maintain the digital Kanban+timeline board, and any stakeholder who is not immediately involved with the team’s work will quickly get an idea of what’s going on with the projects. There’s no limit to this digital timeline, and as to how it can be fit into a screen. Just make sure your screen is big enough for it :) For smaller screens, the scroller — at the bottom right on the screen above — will navigate you through unlimited sands of time.

It looks to me that adding a timeline to Kanban board is more of a burning need, than a luxury. If you want to try timelines combined with the Kanban board, click on the circle on the right.

Related articles:

Visual Management Software

How Timelines Help Project Managers Track Progress

How Visualize: Board, List or Timeline?

Take 5 Visual Reports for Kanban

Categories: Companies

What constitutes “minimally viable agile”?

Silver Stripe Blog - Wed, 06/25/2014 - 07:56

There is an interesting discussion on LinkedIn on “minimally viable agile“. What is the bare minimum that a team should do in order to be considered agile? Should a team do standups to be agile? What if they don’t do standups, does that mean they are not agile, or is it possible to be agile without it? What does it even mean “to be agile”?

This is a topic that comes up every so often without fail. Here are some approaches that are inevitably put forth. I have ordered it in terms of my personal preference, from my least preferred approach to my favourite.

It’s agile if it includes these practices

This school of thought professes a set of practices, like standups or retrospectives, which need to be followed in order to be agile. So, if you aren’t doing retrospectives, then you aren’t agile. The problem with this approach is twofold. First, there are many different agile processes–Scrum, XP, Kanban, FDD, Crystal–and each has its own set of practices, with only very small overlap. So it is hard to nail down a set of practices which MUST be followed. Secondly, there are so many teams that follow ALL the practices, but someone who observes them would not call them agile. Maybe they are co-located, but they dont talk much. Maybe they are developing software incrementally, but rarely release to production and get user feedback.

It’s agile if it follows the manifesto

Another school of though is that it’s not agile if it doesn’t follow the manifesto. Individuals over Process, etc. But there are problems with this approach because it is just too vague. How do you really tell if a team is following the manifesto? The manifesto is a very high level vision statement rather than something actionable where you can go and say, “Yes, this team is following the manifesto”. It can also lead to strange situations, for example a team doing cowboy coding, because the team members just feel like it, would be better aligned to the letter of the manifesto. After all, it is the individuals who have decided to dump the process. But it is hard to think of such a team as being setup for success.

The 7 properties of successful projects

If a set of practices is too constricting, and the manifesto is too vague, then what is the solution?

My guide has been Alistair Cockburn’s excellent 7 properties of  successful projects. Crystal Clear was one of the very first books I read and it made a very strong impression on me, and I’ve been carrying this list around ever since. Unlike other though leaders who are mostly working from anecdotal experience, Alistair’s list comes from specific research into successful projects. Based on this research he identified 4 core properties that most successful projects possess, and 3 additional properties that improve the chance of success, but are not totally critical (ie, it is harder, but possible, to succeed without them).

Here are the 7 properties (top four are the core properties):

  • Frequent Delivery: Do you deliver software to production, at least once a quarter?
  • Reflective Improvement: Do you take time to look back at how you are doing, and where you can improve?
  • Osmotic Communication: Does it take less than an hour to get the answer you are looking for?
  • Personal Safety: Can you give people bad news?
  • Focus: Does the team know what their top priorities are?
  • Easy access to expert users: Does it take less than three days to get an answer from an expert who understands the customer?
  • Strong technical environment: Does the team have automated tests, frequent integration, etc

There are two things that I love about this list.

First, they are outcome based. Take Osmotic Communication for example. Maybe one team might want to make it happen via colocation. Another team might be distributed, but ask all the team members to be online on team chat. Both practices can deliver on the goal: Does it take less than an hour to get the answer you are looking for? Conversely, there may be a team where everyone is sitting together, but they work in isolation without talking. If a team member has a problem, he tries to solve it himself for days without asking anyone. Such a team might be colocated, but they don’t have osmotic communication.

The second thing I love is that it is easy to evaluate. It is not a pie in the sky vision statement. It is specific, and you can easily go to a team and say whether the delivery frequency is good or not, whether communication channels are good or not, etc. It is a great way to figure out where a team stands on the path to agility.

Best of all, it is practice agnostic. This list is applicable whether the team does Kanban, or Scrum, or some custom hybrid.

Categories: Companies

Do You Need an Open Office?

TargetProcess - Edge of Chaos Blog - Wed, 06/25/2014 - 01:10

We’ve been raised in the belief that all humans are social animals, as the theory of evolution has it. If you’re wondering how the evolution and being a social animal is ever related to work in software development, or, more precisely, how it slows down personal and organizational productivity, that’s exactly what my today’s article is about.

Social Animal ≠ Productive Performer

What strikes me most is that we keep on going with the axiom that humans are social animals. Seemingly, we forgot that evolution never stops. With the advances in technology and life infrastructure that happened in the last 30-40 years, the “social animal” concept has suffered some severe cracks. If we look at animals, why are they social? Why they stick together? It helps them feel secure in their natural environment (a flock of deer will sense the danger of the wolves approaching better than one deer), and it helps them get the food easier than on their own (lions, or wolves, hunt in families and then share the meal). Now, do we humans have to gather into a herd, like those animals do in the wild, to secure ourselves or to escape starvation? Obviously, no. But, for some reason, organizations still stick to this thinking as they arrange open-space office layouts for knowledge workers.

Even evolution-wise, the purpose of humans working in an office, to maintain their living, deep down, is no longer to be just fed or to seek shelter. If a contemporary human wants to stay secure and keep “being fed”, the evolution dictates the need to find the optimal ways to perform well at work. “Optimal” stands for “achieve best results with least personal energy consumed”. Staying in physical proximity in one room at work no longer helps our natural evolution, but rather presents a big obstacle to it. With knowledge work, it’s counter-evolutionary and self-sabotaging to expose oneself to the environments that drain us. Numerous research reports prove what people intuitively feel inside:  to keep good health and to perform well, we need to arrange for a space that helps personal productivity, rather than blocks it.

The law of personal energy conservation in the office

Think about it. If you were to count the cases when staying in one room with your co-workers really contributed to your individual performance, and hence to your own well-being and to the well-being of the whole organization vs. how often it was an annoying distraction that sucked your energy that could have been invested into doing the real work? Our co-roomers’ activities have the same effect on us as many apps running in the background have on smartphones. It seems that the phone is doing nothing and just idles, but the battery charge gets lower. The energy is  gone. If you’d need to make an urgent call in the middle of nowhere, with no option to charge it, your smartphone will not be able to accomplish this vital task.

middle of nowhere

It’s about the same with staying in an open-office space. If we throw in to the mixture the other stresses that people have in their lives, things get even worse.

If not an open office, then which one?

How to go about designing office spaces, then? The answer is: it depends on the unique setup and production/development process in your organization. Sometimes sharing a room might work better for a small workgroup, if they rely heavily on a real-communication inside the group.  Like, for a feature team of software developers and QA who call on each other, as they have to verify commits, or if QA’s need help from developers to reproduce a bug, etc.  Or, for customer service employees in technical support and in accounts. It makes sense for them to stay in a shared open-space for their evolution and well-being (read, for their ability to do their work better). However, an open space would be a productivity killer for a strategizer, or for someone who comes up with creative concepts or designs that development teams will then carve in the digital rocks of software. Can you imagine Winston Churchill or Steve Jobs working in an open space office, let me ask? Hardly anyone would doubt that privacy is a must for the highly creative work.

There’s another erroneous consideration that stakeholders might have in mind about open-space offices. They assume that physical proximity will cement people’s belonging to  a cohesive team of individuals who share company goals and values the more, the more time they spend together. Wrong. Belonging to a group can be promoted by other means, such as sharing a company’s philosophy through the space itself, or, what’s most important, by doing some good job together. We wouldn’t think that a family of 4 would have a better sense of a family if they are forced to live in a 200 sq feet apartment, would we? The same is true here. Creating an organizational ethos and having employees light up with it does not happen simply by stowing people in one room. It takes more foresight, thinking and attention to detail. For starters, the team spirit is best promoted by a successful release or by another important milestone achieved together.

This is all about how the specifics of work correlates with the space. While some companies simply do not feel that they can (or should) allocate larger budgets to fine-tune their offices, some people can do just fine working at home, if their home is better conditioned for work than an open-space office. Alternatively, for someone with kids, or with the A/C at home not working, an office would be a better place to work. What and how works better will also depend on the office demographics.  Millenials, the Gen Y-ers, for example, are more likely to put up with the distractions merely due to the fact that they appreciate their office as a space where they can socialize (some say it might be the root cause of why this generation seems to be underpeforming in general). Disclaimer: I’m a Gen X’er :) Not sure if it’s solely for that reason, but I value focused concentration at work more than socializing. This is just another example that shows how deep stakeholders need to think as they approach the job of designing an office. There are so many factors to consider and to write about, that it would take a huge article just to list them all. For each and every company, there will be a unique solution.

Related articles:

5 Things We Need for Sustainable Performance At Work

Continuous Problem-Solving Is No Accident

Getting Closer With Remote

Cognitive Endurance Basics for Software Developers

Top 5 Non-Office Brain Killers

Categories: Companies

Success Story: GLG Boosts “Customer Equity” with Assembla

Assembla Blog - Tue, 06/24/2014 - 17:25
GLG Logo Challenge

Garrigan Lyman Group was worried about losing the loyalty of its own customers. The agency was expanding rapidly and tackling more complex e-commerce, mobile, social media and video projects. Clients had no visibility into when new requests would be delivered. Development managers were having trouble tracking releases and matching resources to requirements. Teams needed a solution to prevent missing deadlines and ensure the quality of delivery.

Objective

Chris “Whitey” Geiser, GLG’s CTO, knew that the agency could not afford to lose “customer equity,” the hard-won confidence that GLG could deliver innovative digital marketing solutions. So he and his team began looking for technologies that could help them centralize processes, manage development requests, and improve communications with clients.

Results

Assembla has helped Garrigan Lyman Group win new business from existing clients. The solution has helped GLG evolve from helping clients with flashy but self-contained marketing projects, to solutions that work with the core of their businesses. It allows the company to collaborate better with clients and improve control of their development processes.

To see how GLG learned to work more closely with its customers,
fill out the form below to download the full case study.

//

Categories: Companies

The Insanity of the 1s and 0s Trap

NetObjectives - Fri, 06/20/2014 - 08:15
I’ve been fortunate enough to be at several conferences with Don Reinertsen. I love being next to him watching a talk together.  More than once I’ve heard him remark – “people in this industry are too used to working with 1s and 0s and forget there are other options.”  Unfortunately, our two most popular (or perhaps, I should say – most being pushed for certification) are Scrum and the Kanban...

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

Identifying root causes using the 5 Why technique

Silver Stripe Blog - Tue, 06/10/2014 - 08:21
​One of the important steps in a retrospective is to identify the root cause of a problem that the team has identified. If we don’t do that, there is a risk that we will spend a lot of time trying to fix superficial symptoms. 5 Why is a technique to help with this.

Example: Solving a dependency problem

Suppose a team identifies that they got blocked by a dependancy. One of the dependent teams didn’t deliver their part of the work, and so the team couldn’t complete their user story.

Now the team has to figure out what action they can take to reduce the likelihood of it reoccuring in the future. Some ideas come up like:

  • Follow up more frequently with the team
  • Escalate the issue to their manager
  • Explain to the team how important this story is
  • Escalate the issue to the team’s PO
  • … and so on

Here, the team is directly addressing the problem and coming up with possible solutions.

An alternative way using 5 Why technique

Now, suppose instead of solving the dependency issue directly, the team tries to find the root cause. The way to do this is to repeatedly ask “Why did this happen?” for each level of the cause that is uncovered. This is how such a discussion might go:

  • What happened?
    • We were blocked because of a dependent team that didn’t complete their part of the work
  • Why did this happen?
    • Well, they got the request too late and didn’t have time to stop their other work and complete it
  • Why did they get the request so late?
    • We didn’t know about the dependency until we started working on the story
  • Why didn’t we know about the dependency?
    • We had not groomed the story before hand
  • Why didn’t we groom the story before hand?
    • The PO didn’t have the story ready at that time
  • Why didn’t the PO have the story ready?
    • We didn’t have visibility on the plan for the release
  • Why didn’t we have visibility on the plan?
    • We didn’t do any release planning

So the root cause here is that the lack of release planning caused a chain of events that eventually led to a dependency blocker problem at the sprint.

The place that this team really needs to concentrate on is on doing a good release planning. If they do this, then it will eventually reduce the blockages due to dependency with other teams.

The goal of the retrospective

The example above shows the difference between tackling issues at the surface level vs solving the root cause. As long as the team focuses on how to manage a mid-sprint dependency, they are not going to solve the issue. They will keep getting this problem again and again in the future, since the root cause is not addressed.

Also, it initially seems as if the solution is outside the scope of the team and there is nothing much that can be done apart from follow up and escalation. But the root cause is actually within the team and can be easily solved by the team themselves.

Finally, once we fix the root cause, we will have much fewer mid-sprint dependencies. The problem simply goes away for 75% of the cases.

A good perspective when tackling these kinds of impediments is:

Stop focussing on how to manage a problem, instead think about how we can prevent the problem from even occuring in the first place

Categories: Companies

Episode #138 – Principles or Practices

Integrum - Agile Weekly Podcast - Thu, 06/05/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What is more important, principles or practices?
Email
Categories: Companies

How to Scale Agile Software Development

Scott W. Ambler - Agility@Scale - Wed, 05/28/2014 - 09:39

The following diagram summarizes a safe and proven strategy for scaling agile delivery strategies at the team level.  There are three features of this strategy:

  1. Basic agile and lean methods.   At the base are methods such as Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Agile Data, and many others.  These methods are the source of practices, principles, and strategies that are the bricks from which a team will build its process. 
  2. Disciplined Agile Delivery (DAD).  Building on mainstream methods is the DAD process decision framework, providing an end-to-end approach for agile software delivery.  DAD provides the process mortar required to combine the process bricks, effectively doing the “heavy lifting” to describe how all of these great agile strategies fit together.
  3. Agility at scale.  Teams operating at scale apply DAD in a context driven manner to address the scaling factors that they face.  These teams may be large, they may be geographically distributed in some way, they may face compliance constraints, they may be addressing a complex domain or technical environment, or they may be organizationally distributed in some manner.  And usually combinations thereof.  Without the solid foundation provided by DAD, agility at scale is incredibly difficult to achieve.

image

To scale agile successfully you must be able to tailor your approach to reflect the context that you face.  To do this you must understand what your process and organizational structure options are and what tradeoffs each of those options has.  Unless you’re a process expert, this can be challenging.  This is where DAD’s process goal strategy comes in.  Instead of prescribing a single way to do things, as we see in methods such as Scrum and SAFe, DAD instead captures your options in terms of process goals and guides you through making the decisions that best address the situation that you find yourself in.  An example of a process goal diagram, in this case for the Inception phase goal Explore Initial Scope, is shown below. 

image

The critical thing is that with a goal-driven approach it becomes much easier to understand how to scale agile.  Depending on the context of the situation that a team finds itself in you will address each goal differently.  The strategy for a small, co-located team facing a fairly straightforward situation in a non-regulatory environment works well for that team, the same strategy prescribed to a team in a different situation would put that team at risk of failure.  Instead of prescribing a single way of working that is optimized for a specific situation we need to instead allow, and better yet enable, teams to adopt strategies that reflect the context of the situation that they face.  

We’ve found that four of the twenty-two process goals seem to take about 80% of the tailoring impact.  These goals are:

  1. Explore Initial Scope. This is sometimes referred to as initially populating the backlog in the Scrum community, but there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.
  2. Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. You want to address this process goal for several reasons . First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into Construction.  A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle.  It can also help to avoid injection of unnecessary technical debt as a result.  Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources that they can potentially leverage while producing the new solution desired by their stakeholders.  By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse.  You will do this by working with your organization’s enterprise architects, if you have any.  This is an aspect of DAD’s philosophy of working in an enterprise aware manner.
  3. Move Closer to a Deployable Release.  This Construction phase process goal is important for three reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution).  This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy.  Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.
  4. Coordinate Activities. Although it is nice to believe that all of the coordination required by an agile team can be handled with a 15 minute stand up meeting every day the truth is far from that.  This process goal addresses strategies for coordinating the work within a team, coordinating with other development teams (if needed), coordinating with IT groups such as your Enterprise Architects or data management group, and coordinating between subteams a programme or portfolio.

For a more detailed discussion of how these four process goals are the key to scaling your agile software delivery process, please refer to the whitepaper Scaling Agile Software Development: Disciplined Agile Delivery at Scale.  

 

Categories: Blogs, Companies

Being a change agent

Silver Stripe Blog - Sun, 05/25/2014 - 11:15

Yesterday, I spoke at Absolute Agile @ Hyderabad. The topic of my talk was 1/3 Agile, or being a change agent. The slides are above, but they don’t make much sense on their own, so here is some explanation for the slides: What does it take to be agile?

There are three areas to focus on to improve agility:

  • The process itself: stories, feedback, incremental and iterative development…
  • Building strong teams: Self organisation, collaboration, continuous improvement…
  • Using effective technical practices: TDD, continuous integration, clean code…

Out of these three, most organisations focus a lot on the process, but ignore teams and technical practices. This leads to what I call 1/3 Agile, where we are limited to only a subset of the benefits.

What stop us from building better teams and using better technical practices?

The audience raised a number of obstacles that stop them from having strong teams and tech practices. These obstacles generally fall into three buckets:

  • Culture: Some say that their organisation culture is still command and control, and these practices wont work there
  • Authority: Some say that they don’t have the authority to make the change, and it must come from senior management
  • Skillset: Some say that they would like to do these but don’t know how
What now?

We have two options when faced with these obstacles.

  • We can give up and stay with the status quo
  • Or we can be a change agent and shape the future

Do we want to be remembered as someone who wanted to do something great, but wasn’t allowed to by the organisation, and in the end you did nothing of note? I hope not :) and in that case, the other option is to be an active change agent.

Being a change agent

Three vital skills that we need to put to use are:

  • Showing leadership
  • Building relationships
  • Exerting influence
Showing Leadership
  • First, leadership doesn’t require authority. Anyone can be a leader–it is not reserved for the executive management. In fact, in 99% of the time, leaders do not have authority. Even in the case of senior management, whom employees assume have the most authority, most of the work is done without authority. This is because a lot of work involves collaboration across many groups and departments and unless you are the CEO, you don’t have authority across the organisation. So we have to dispel with the notion that leadership requires authority.
  • Before the transformation, team members may be thinking of their job as showing up, writing some code or testing, collecting a paycheck and going home. They may be thinking the same during the transformation as well. So they may not care about the transformation: agile, waterfall, whatever it is is irrelevant, and you won’t be able to make a strong team if they don’t care. You need to ask them: why are we here? what are we doing? where are we going?
  • When it comes to teams, the first step of to take is to communicate a vision. Most of the time, there is a lack of vision. Team members don’t know why they are doing this “agile thing”, apart from the fact that someone, somewhere said that the company is going agile (what does that mean?). It is up to you, as the change agent, to make sure the teams see a vision where strong, self organised teams are creating great software. Without teams buying into this vision, nothing else will bear much fruit.
Building Relationships
  • There is a saying: “Role power gives compliance, relationship power gives commitment.“ 
  • Role power is the authority derived from your role. or designation, in the organisation. When you ask someone to do something from a position of authority, they will comply. Their performance appraisal and paycheck depends on it. But they may not be enthusiastic about it. They might just do the minimum required to make you happy, and then stop.
  • There is another source of power in an organisation and that is relationship power. This is the power from having good relationships with other people. When you need something done and you leverage a good relationship, it gets done because the other person believes in you or trusts you. They always have the option to decline, so the fact that they are doing it means they will do it a lot better. They are not doing it just to comply with you.
  • Compliance has no lasting power. The moment you look somewhere else, the compliance will stop as well. Commitment is the only way to build long lasting change.
  • Building relationships is important. Of course, build relationships with the teams you work with, but also build relationships with others in different places in the organisation.
Exerting Influence
  • Al Switzler and the folks at VitalSmarts have a book called Influencer. Their influencing model is based on six leverage points on influencing which fall into 3 categories: Personal, Social, Structural
  • Personal is when you try to change a person’s outlook directly
  • Social is when you use peers, groups, communities to influence change
  • Structural is about changing the system or environment in such a way to influence change
Alignment
  • When trying to make a change, it is important to align the message to the person or group. Only when it is aligned is there motivation to make the change.
  • For example, if you are trying to transform a team, you need to first understand what each individual wants from their work. Some may want an opportunity to write beautiful code. Others may want the excitement of delivering value to their customers. Some people want work life balance to spend time with their kids. You need to show a vision of how agile can help team members reach these goals in the future. Maybe you will emphasise technical practices to the first person, and rapid incremental delivery to the second one, and sustainable pace to the third one. Of course, you will also explain that this is the end state, it may take many months to get there, but you will get buy in for going on the journey.
  • Similarly, when talking to senior managers, you will need to align with their goals. Maybe they care about time to market, or innovation, or delivering quality with high customer satisfaction.
  • If there is no alignment, there will be no buy in. If you talk to developers about time to market, they may not care; they may thing that agile is just a way to manipulate them to get more work from them. Same way if you talk to a manager that agile gives work life balance, they may not care; worse, they may think that it is a touchy-feely thing which will reduce the company’s profits.
  • Often times, a big problem is that a few people believe in agile and they declare a transformation for the organization. But the vision is only from their point of view. For example, a CEO might tell at an all-hands, that we are adopting agile because we need to deliver faster to the market. But unless the message is translated to benefits for all the other people in the middle — from senior management, middle management, first line management, and team members — then without that no transformation will happen. Maybe something might happen only to comply with the directive, from the role authority of the CEO. But there will be no commitment. It will fizzle out.
Culture
  • One of the biggest obstacles that gets highlighted is that of culture. Be it organisational culture, or the Indian culture, it is the most common reason given as to why team practices and technical practices cannot be implemented.
  • Some people say that Indian culture is by nature command and control, right from schooling to the society, and the same continues even when people come for work. Hence self organisation cannot work.
  • Others say that Indian companies are built as command and control organisation and cannot be changed.
  • Still others say that since most Indian companies are service companies with clients abroad, and their USP is about competing on price, hence command and control is required.
  • I don’t buy these arguments. There are companies in India where self organised teams are a reality. These companies are hiring the same Indians as everyone else. Hence I don’t buy the argument that self organisation is not possible in India due to culture. There is something more to it.
  • Similarly, even in highly command and control organisations, there are certain departments or teams where the culture is different.
  • If we look at it, there are three levels of culture: The country culture, the organisation culture, and the team culture. Generally, team culture overrides organisational culture, which overrides country culture. Certainly all the cultures have an impact, for example when dealing with other departments, the organisation culture may play a primary role. And when dealing with relationships, country culture is primary. But at a team level, it is possible to create your own cocoon of culture through leadership and relationship building.
  • Lots of people talk about culture as an excuse for not even trying. This is the big mistake we make.
Running your own experiments
  • Sometimes the reason given for not trying team and technical practices is that someone in the organisation will not approve of it.
  • Actually, the truth in most organisations (especially larger ones) is that as long as the deliveries are being met, generally no one cares what else you do. So, if the team is excited about TDD, they can just go ahead and do it and no one will even notice. Just make sure that the delivery is not getting messed up, and you wont attract any attention to yourself.
  • What this means is that it is possible to make incremental changes for the better, slowly over a period of time. Just make sure you don’t tell anyone :) It is only after you become successful that people will even take notice.
  • There is a quote attributed to Grace Hopper: It is easier to ask forgiveness than it is to get permission
  • In some organisations, it is better not to ask. Some people are tuned to saying No for anything that they don’t understand. Often you can just go ahead and do your changes and no one will even care. And later if someone questions, then you can show them the benefits you are getting.
  • Sometimes, running experiments this way sounds risky and change agents are unwilling to place themselves in a vulnerable spot like this. But a change agent has to do it. Hopefully, you have built relationships with others that will reduce this risk.
Networking
  • Do not ignore networking. Take every opportunity to build relationships with others, especially people outside your team or department.
  • Social capital is very very important for making change happen.
  • In his book Tame The Flow, Steve Tendon contrasts span on control vs sphere of influence.
  • Span of control is the number of things that are directly under our control. Usually this is quite small — maybe the team, perhaps a few more things.
  • Sphere of influence is the number of things that we have no direct control over, but we can influence. We can get things done in the sphere of influence, but it has to be done via someone else.
  • Being able to get things done through other people is the single most important skill for a change agent, and this is only possible through having good, strong relationships.
The power of community
  • One person cannot drive a large change. It is vital to build a community to support the change. Find the folks who are supportive, and encourage them.
  • Don’t limit the community to a single role. Who knows, maybe there is a director in another department who is interested in agile. Welcome her. Maybe she could influence the director in your department who is lukewarm to agile.
  • A healthy community also helps to drive social influence. People are most likely to listen to peers. If their peers are talking about self organisation or technical practices, then they are more inclined to try it than if an external person like you tried to convince them.
So, what is YOUR vision?
  • Being a change agent is a unique opportunity to learn and put into use crucial skills that are very important to career success
  • Don’t wait for change to miraculously happen from elsewhere
  • Don’t wait for the organisation culture to miraculously change before you take the next step with your teams
  • Building these skills takes a long time, and lots of practice, so start today!
  • Remember, that YOU can make the difference

 

Categories: Companies

Episode #137 – Central Control

Integrum - Agile Weekly Podcast - Thu, 05/08/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • What happens when someone has central control

Transcript

Derek Neighbors:  Hello, and welcome to another episode of Agile Weekly Podcast. I’m Derek Neighbors.

Roy van de Water:  I’m Roy van de Water.

Jade Meskill:  I’m Jade Meskill

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich

Derek:  We’ve got another fantastic, hypothetical situation.

[laughter]

Derek:  You may spot this in the wild, I don’t know. We’re talking about things that could potentially maybe happen, someday, to some teams.

Say you had a czar of a department, or a unit, or a job function.

Roy:  Like a real Russian Tsar?

Derek:  Yeah, like an architect…

[laughter]

Jade:  I’m a Marxist, sorry.

Derek:  In the hypothetical situation, we would probably see this as being an architect, or maybe be a designer of some kind. When I say designer, I mean the chief of the companies, the [inaudible 00:55] top guy.

Jade:  Or the head programmer?

Derek:  The head jock honcho.

Jade:  On the team, the technical lead or something?

Derek:  Not even that. Above the technical lead, the top of the food chain. They have this stance that says, “The only thing that can done can only go to production if I have approved it.”

Roy:  You’re saying everything has to go through this guy?

Derek:  Everything has to go through this gal. She is totally 100 percent, “The design, every pixel has to be done by me,” or “Every single method has to be approved by me if we’re writing code.”

This person works in a large organization, thousands of people per se, and lo and behold, they can’t go to every planning meeting.

The good news is they have some mini‑czars that they can send out to these planning meetings. They can go to these planning meetings, and help the developers and the designers do things.

Then what happens is all sorts of decisions happen in a planning meeting. When these mini‑czars come back to the big honcho, the big honcho says, “Nope, I don’t like it. It needs to be this way.” Now they go back to the team and have to tell the team, “Sorry.’”

[crosstalk]

Derek:  …What does that look like? What happens? How do you fix that? How do you rectify that situation? What are the downsides to that stuff?

Roy:  First off, is there anything wrong with that?

Clayton:  Yeah, I’ll take the devil’s advocate approach. The reason that all the design has to go through that one person is because if you want to maintain a consistent brand experience for the end‑user, you can’t just let people ‑‑ especially developers who don’t have any design sense ‑‑ to go off and do a bunch of crazy stuff.

Roy:  There’s a bunch of awesome examples where I’ve seen exactly that with Google. In fact, I’ve heard, Derek, you complained about this specifically that Google has all of these products out there of totally different experiences, that are totally not integrating because they’re all being developed in isolation.

Derek:  Ever since their designs are [inaudible 02:56] left…

[laughter]

Derek:  They have not been on‑brand.

Jade:  I’ve seen these on the development side, too, where you’ve got all these dumb programmers that we hired that are up there writing a bunch of crap. If they could just do it like me, everything would be so much better.

Derek:  Yeah, where do you think our tech‑level of that comes from?

Jade:  Yeah. [laughs]

Clayton:  I suppose we pay these people six figure to be morons.

Derek:  The dumbest, highest paid people, we have.

[laughter]

Roy:  I get that. The guy at the top, his neck is on the line if should go south, he wants to make sure that everything goes north. Right?

Derek:  Yeah, it’s pretty scalable, they are able to ship a lot of production software this way.

Clayton:  That’s a trade‑off. If you go through this bottleneck where one person has to approve everything, obviously everything goes very slowly, and you don’t ship very often.

Jade:  And you redo a lot.

Clayton:  Yeah, you probably use a lot of rework, as obviously the market’s going to change, and you’re going to have to go back and fix things and change your strategy. But theoretically, everything looks pretty good, and it’s pretty close to being “perfect” when it does ship.

Roy:  I guess that depends on their value system then. Do you value the ability to move fast, to make changes and respond to changing requirements in the changing world? Or do you prefer to have a perfect experience? Because I could see value in both of those.

Derek:  Yeah, if a lot of people really applaud Apple and Steve Jobs and what he did ‑‑ he certainly was not interested in shipping on a very tight schedule and going very fast. He was much more concerned about shipping perfect products than he was shipping bad products more frequently.

Roy:  Right. Another example is like Rolls‑Royce or something, where, I don’t care if it has the latest and greatest features, but…Hold on, let’s be clear here. I’m not buying a Rolls‑Royce.

[laughter]

Roy:  I could see people don’t really care about [inaudible 04:46] features, they care about every product being extremely high quality. I don’t know if they actually have this, but I could see them having a philosophy like the CEO hand‑checks every single car before it leaves the factory, because they insist on having that premium experience, and that everything is perfect.

Jade:  Apple’s an interesting case, because they’ve shipped a lot of great hardware. They shipped a lot of really poor software that is not consistent and not very good.

Derek:  You’ve obviously used their online store before.

Jade:  [laughs] Yeah.

Clayton:  I’ve always had a tough time with the Apple comparison. I think that’s the first one that people jump to, but no one ever really acknowledges the difference in hardware.

Jade:  It’s much harder to fix hardware once it’s gone up the book.

Clayton:  Yeah, so that’s different. That’s something that we should clarify.

Derek:  When I look at this hypothetical situation, the thing that I think is the biggest pain for me or the biggest thing that I see that people aren’t talking about, is what does it feel like being a team member who goes through a planning meeting with a group of people and comes up with a solution and an idea only to, an hour later or a day later or two days later, say, “Uhh, what you’re doing is really stupid and really dumb. This is the right way to do it. Throw away everything you’ve done and go do this other thing instead.”

What does that feel like as a team member, do you think?

Roy:  I can see two parts to that. First off, we talked a lot about autonomous teams. I would feel like, as a team member, a large part of your autonomy gets taken away if someone comes back and says, “You have to do it my way.”

If it’s taken from the standpoint of, “Hey, have you considered using other options”? And they are truly better ideas. If you follow the core commitments and you choose to always seek to better an idea and to accept any idea no matter where it comes from, then that sounds like it would only be a positive experience.

I think that how that interaction takes place, and the attitude of both parties, has a huge impact on how that’s going to go down.

Clayton:  I would feel pretty useless and like my time was being wasted. I would probably not even bother attending. Or if I did attend, it would just be for show. I would probably not even be paying attention because, really, what difference does it make?

Roy:  But there is a difference. Clayton, if I came to you. Let’s say you plan on a Monday and I come to you on a Wednesday. I say, “Hey, I saw what you guys planned out on Monday. Have you considered using other possibilities”? Would you have that same reaction?

Clayton:  If you said, “Had you considered these other possibilities”? We had some dialog, and I said, “OK, let’s talk about it next Monday.” I think that would be one thing. If you said, “Put the brakes on. Really think hard about these other choices, because you’re doing them no matter what.” Then I would feel like, “What’s the point. Why did I waste that time”?

Jade:  I can tell you what it’s like to be on the other side of that. I’ve been that person. It sucks. You can’t trust anybody. You are paranoid and you need to be…

Roy:  Just to be clear, what side are you talking about?

Jade:  The person who’s the bottleneck. Who…

Roy:  Oh, I see.

Jade:  …is changing things for everybody.

Roy:  And insisting that your rules be followed?

Jade:  Yeah. It’s a very crappy position to be in. You don’t sleep well. You’re not relaxed. You’re always stressed out because everything is going wrong around you all the time. You don’t trust anybody. I think that’s really where…that’s the core of the issue. You don’t trust anybody.

Derek:  In this particular hypothetical, there’s also a middle person. We’ve not talked about that middle person. Not only is the person that is doing the work probably leaving frustrated…

Roy:  So you’re talking about the Vice Czar in this, right?

Derek:  The Vice Czar goes into this thing thinking, “Oh, I totally represent the attitudes and the patterns and the thinking of my boss.” We go in and I walk out thinking, “Man, this is all going to be really good.” Then I go back and they say, “Why did you make this decision? You’re letting them do that? I can’t believe that”!

Now, not only do I have to feel like maybe my boss doesn’t trust me, but now I have to go deliver that news to a whole group of people to say, “Hey guys, even though I said that this was probably the right thing to do, as it turns out, the Grand Czar does not agree with me.”

What does that got to feel like?

Clayton:  You lose face with the other people. I know that I told you that it was good, or that we agreed that it was good, but it turns out that it’s not. So either I can play that off as, “The czar guy is a real jerk. Man, what an asshole! I hate that guy too.” Or you would have to just hope that people aren’t thinking, “This person is really stupid. They don’t understand what their boss wants. Man, I’m not going to bother asking their opinion anymore.”

Roy:  Right. Even the boss is probably getting frustrated with them. They’re coming back with ideas representing the team. It’s probably not what the boss wants in the first place. They’re never going to think the same way. So this person is probably just getting shit on from both sides.

Derek:  So we’ve got the hypothetical. We’ve got some of maybe how it feels to be all of the roles in the hypothetical. How would you go about fixing it?

Roy:  In my opinion, if you can figure out some way to have the team earn the Czar’s trust and rid the organization of the Czar, not rid of the person but rid of the role, I think that will go a long way. Somebody who is insistent on all of these best practices, good coding styles, good design, or whatever, they should be going out and championing all of those things and explaining why it’s so important and really convincing people and winning them over rather than telling them what to do.

Jade:  A lot of times they do have a lot of really great knowledge and sometimes even some special insight that other people don’t have, but you’re right.

They should be going out and helping those other people to gain that skill and also experience things from the other side of the fence.

The things that are changing during planning or the real complexities on the ground of dealing with this on the fly, those type of things so that there is some empathy for what the people are going through while they’re out dealing with these situations.

But again, it comes back to building trust with those people. You believe that they’re doing the best thing that they can.

Roy:  It gets tough though when you set up a system like that in which you’re like, “I’m the one who is going to decide on the design, so Clayton don’t even bother wasting time coming up with designs or whatever.”

“Don’t even bother coming up with the method definitions because I’m going to shoot it down and give my own implementation anyway.”

Now all of a sudden Clayton hates me, and it’s going to be really difficult for Clayton to earn my trust because he is going to be trying to get away as much as he can to please the people that are breathing down his neck without getting my ire.

He is going to be subverting me, which is going to cause me to trust him even less like that’s just going to be a feedback loop.

Clayton:  There are definitely cases where people get in this situation like what Jade described like no trust and I don’t think most people would want to be in that, but there are some people who do enjoy the aspect of controlling everything.

They want to be the hero and they want to be seen as the smartest guy in the room and all that stuff.

I would say that probably is a pretty big component in a lot of these cases compared to the person who really doesn’t want it to be that way all the time, but it’s just like, “Oh, woe is me,” it just happened to be that way.

There is some aspect to that. I think unwinding some of that desire for control where they don’t feel like all of their self‑worth at their job is based on whether or not they got all the answers right all the time. I think that could go a long way.

Derek:  When I look at it, Steve Jobs might be a good example. I didn’t know Steve and I certainly didn’t see him work, but I would…

Roy:  Me and old buddy Steve, yeah.

Derek:  I think that if I were to…

Roy:  I call him Steve.

Derek:  …guess how he operated, he trusted his people. Because I don’t think he could get the results he got without trusting them. What he wanted to control was the essence of the spirit of the products that were put out.

Not necessarily how they were built and so to me the difference is you come back from a planning meeting and I say, “Oh my God, you’re doing all the stuff wrong and this is how you should have done it.” I don’t think that’s how Steve operated.

He probably operated in a “I’m going to let you do whatever and when you show it to me, if it’s crap, I’m going to say it’s crap, but I’m not going to ship that and fuck you go do it right, and when you get it right, we will ship it. Until then, leave me alone, don’t waste my time.”

“Why did you call me to this fucking demo that sucks this bad”? What I think is very, very different than saying, “I’m going to tell you exactly how to do every little thing.”

I might tell you at the demo to say like “I’m not doing that and I had expected this.” And I think that’s a subtle difference, but that’s very different than trying to control how everybody does their job.

Instead of saying here’s the bar of expectation and I’m going to make you live up to that, I’m not going to tell you how to live up to it.

Jade:  I think that’s right.

Derek:  How do you get somebody to get to the point where they’re allowed to let the essence of what their standard is hold but not have total mistrust.

Jade:  I think there are some systemic problems in that as well that that person is probably being held accountable for those decisions by their people.

Getting some understanding put in place there is a big help. To help their boss see that like they don’t need to be held to that.

They need to be held to the standard of they’re making everyone around them better and helping them achieve that essence and not being a control freak.

Because usually it’s people that don’t want to do that. They end up in that situation because of some externality.

Derek:  Right, fear usually, they’re afraid of something.

Roy:  I wonder if people that are successful at it and managed to climb their way to the top might not be the ones that enjoy it though.

Jade:  There are people that enjoy having that control like Clayton said, and those people might not be able to help them.

Derek:  All right. See you next month.

[music]

Announcer:  Is there’s something you’d like to hear in a future episode? Head over to integrumtech.com/podcast, where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at AgileWeekley.com. It’s the best Agile content, delivered weekly for free.

The Agile Weekly Podcast is brought to you by Integrum Technologies, and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com, or subscribe on iTunes.

Need help with your Agile transition? Have a question and need to phone a friend? Try calling the Agile Hotline. It’s free. Call 866‑244‑8656.

Email
Categories: Companies

Four ways to make agile ceremonies more productive

Silver Stripe Blog - Tue, 05/06/2014 - 09:21

​One of the common complaints about agile is that there are too many ceremonies. The issue isn’t with meetings per-se. The problem is that too many of the meetings are not as productive as they could be. Here are 4 ways to make the meeting more productive:

Keep the ceremony on track

A common cause for an ineffective meeting is that the conversation goes into tangential topics and the meeting outcome is never met. This leads to another meeting to be scheduled, or delays in the work. Here are some examples:

  1. ​In a grooming meeting, the conversation goes away from preparing upcoming stories. The PO and team instead start discussing the status of current stories. By the end of the meeting, none of the stories are groomed. When the next planning meeting came around many stories will not be in a position to be picked up.
  2. In a daily standup, the discussion goes towards solving one particular blocker. The whole team is standing and getting totally bored while two team members have a long discussion on the blocker.

In all these cases, keeping the ceremony on track would have saved everyone some valuable time. The next time you notice a discussion going on a tangent, put the discussion on the parking lot, or schedule another meeting specifically for that discussion. Then get back on track for the reason you have set up the meeting.

Reduce distractions

Be sure to run meetings without laptops and phones on silent. The biggest meeting killer is when someone is talking and meantime everyone else is checking email or doing something else. When folks are distracted, the meeting loses its purpose, and further discussions have to take place during the to go over the same ground that was covered in the meeting. When everyone is focused, the meeting can be finished earlier and everyone can get back to work.

Set aside certain slots for scheduling meetings

Software development requires a block of time to concentrate. Having a meeting in the middle can disrupt that time. It is better to have a 60 minute meeting followed by 4 hours of coding time, rather than 2 hours of coding time, then the meeting, followed by another 2 hours of time. Agile ceremonies happen on a regular schedule, so you can easily schedule them in the most convenient time. For example, some teams schedule all their ceremonies in the morning and keep the afternoons free of meetings. This is more productive than randomly having meetings throughout the day.

Ensure that the ceremony pre-requisites are met

A few days before the ceremony the Scrummaster or team should make a quick check that everything is ready. For instance, the stories should be well formed, and ready for discussion. If they are missing acceptance criteria or there are outstanding decisions to be taken, then the story should be de-prioritised from the discussion. Otherwise you will waste time in the ceremony going off track. Similarly, if some architecture review was identified in the grooming, then ensure it happens before the meeting.

Categories: Companies

Episode #136 – Simple

Integrum - Agile Weekly Podcast - Thu, 05/01/2014 - 15:00

Derek Neighbors, Jade Meskill, Clayton Lengel-Zigich, and Roy van de Water discuss:

  • Simplicity

Transcript

[laughter]

Clayton Lengel‑Zigich:  It is hard doing that every week.

[laughter]

Derek Neighbors:  You don’t do it quite as good as Jade does.

Jade Meskill:  All right, go Roy.

Roy van de Water:  Hello and welcome to another episode of the Agile Weekly Monthly Podcast. I’m Roy van de Water.

Jade:  I’m Jade Meskill.

Clayton:  I’m Clayton Lengel‑Zigich.

Derek:  I’m Derek Neighbors and joining us today is the improv group.

Roy:  In the room next door.

[laughter]

Jade:  Yelling very loudly.

Roy:  Today we are talking about thinking simply, instead of thinking complexly. Jade, you and I have been…

Jade:  Accused of being simple?

Roy:  Accused of being simple.

[laughter]

Roy:  Can you tell me a little about what that idea means?

Jade:  Sure. We’ve been trying to…

[shouting in background]

Jade:  These guys are really… [laughs] yelling in there.

[laughter]

Roy:  I’d like to denote that they were entirely quite for the last 45 minutes before we walked into this studio.

Derek:  It’s like they’re Chicago trading for [indecipherable 1:10] .

[laughter]

Jade:  Buy! Buy! Sell! Sell! [laughs]

Derek:  You do the savings, I’ll do it.

[laughter]

Jade:  We’ve been working on some concepts of trying to write very, very small, simple applications, taking the UNIX philosophy and applying it to web applications to avoid the over‑complication that tends to arise in larger systems.

Roy:  What does an over‑complication look like?

Jade:  Usually a system where the responsibility is not very well delineated between either modules or different parts of the application. It tends to be very messy and sloppy, where it’s hard to tell where something…There’s no discrete functionality, I guess is the best way to say it.

Derek:  The way that I think about it is, if you had a web application where the code that displays the page where you enter in the details about a job is in the same place as the code that makes the…Say the job in a database in the same place in the code that schedules the job, in the same place in the code that runs the schedule of job, in the same place in the code that…They’re all in the same place.

Roy:  It sounds like everything is in the same place, it sounds pretty simple to me.

[laughter]

Derek:  Right, until you get everything in the same place, and then something goes wrong, or you want to change something. We have this problem with the Agile Weekly podcast or Agile Weekly website, where we had a bunch of things that were all clinched together.

If I took the approach of a normal, say, Rails application, like the standard Rails way of doing things. When certain pieces of the system got a little too big, or too unwieldy, it was hard to…it seemed like it was simple because it was all in the same place, but the real simplicity came when we broke those out into little pieces.

Then you have these…you’re going back to [indecipherable 3:08] sampler, mentioning the UNIX philosophy, with these little teeny pieces that all did their one little thing really well. They all just worked together.

Roy:  So why wasn’t it obvious to be that way in the first place?

Jade:  Because in the beginning that would have actually been more complex.

Roy:  So how do you know when you are doing something complexly instead of simply?

Jade:  I think when it becomes hard to explain, it’s probably too complicated.

Roy:  Is that like the metaphor ideal, like you should be able to describe whatever you’re building as a metaphor, and as soon as your metaphor circuit is breaking down that means that you’re putting too much in there? Is that…

Jade:  I think that’s a good way of putting it. If it’s not something that you can explain in a simple, conceptual way, it’s probably gotten a little bit out of control.

Roy:  Is this idea of complexity versus simplicity something that is on the overall project, or is it something that you see replicating down to the individual components of a method, or a class, or something like that?

Jade:  It’s an important recursive idea that happens. If you are being simple with the very small parts of your system, it’s easier to be simple at the larger scale as well.

Derek:  I think developers in general…they find it easier to think in these terms when they’re maybe down in the class with the [indecipherable 4:31] methods. I think that’s where they live, and all that stuff. Then you go up a few levels and even talking about what features you’re delivering.

I think a lot of developers might understand that concept at that level, but then it gets in the features and it’s like, “Well, the product guy said just build this stuff, and like well, OK, whatever, I don’t care.” Where I think that’s the even more important part, that’s an equally important part to be having this discussion about simple…

The planning meetings that we’ve been involved in lately for sure. I think we’re constantly driving towards trying to find something that’s simple, but not too simple, or not too simplistic. That’s a really hard thing to do.

Jade:  Yeah, I think being simple is hard.

Roy:  So this is the type of thing that I might solve using design patterns, like, “Can I just throw those at this problem?”

[laughter]

Jade:  We have an observer. Let’s find out…

[crosstalk]

Clayton:  I think the interesting thing to me, it’s always easier to add complexity that it is to remove complexity. When you start to get that Zen peace, it’s way easier to say, “Let’s start super simple and we can add what we need to add,” which is a very hard discipline to build.

Even if you’re talking product. That struck it for me. Can’t say how many times you’re talking about a feature and you’re up there at a whiteboard drawing it out, and somebody’s like, “Well that’s just too simple.”

At the end of the day, if you give this to the developers, it might turn into a two‑week feature request even though it sounds so simple right now, on the surface. As human beings we like to overcomplicate everything all the time.

Roy:  What drives that, though? Why do we want to overcomplicate things?

Clayton:  Some of it is uncertainty, or, we have this need for completeness. If we only say we’re going to show X, it’s like, “Yeah, but Y and Z and A and B are all available to us, too. We have to show them.”

“Why? What if we just showed X? What if X is enough? That is all that feature needs, why do we need the…”

“Because those other things exist, so we have to show them.” There’s very much this, because we can, we should, mentality.

Derek:  Another thing we see in our work is that people have an aversion or misunderstanding of iterative development. It’s like, if we don’t do this now, we’re…

Jade:  You mean incremental development?

Derek:  Yeah. If we don’t do this now, we’re never going to do it. If you guys don’t plan every single thing that we think we know, then we’re totally screwed. You guys are going to forget it.

To be fair, I bet you there’s a lot of product people out there who have teams that maybe aren’t the most reliable and don’t deliver what they say they’re going to deliver, and all those things.

When someone were to come in and say, “Hey, we’re going to do some really simple thing and ship it real soon,” it’s like, “Yeah…I don’t believe you.” Like, I’m not going to take that risk.

Clayton:  To me, it sounds like there’s a little bit of the 85‑15 rule, where you can deliver 85 percent of the value with 15 percent of the effort. Then you spend the other 85 percent of your time delivering the last 15 percent of the value.

I have worked with different product people, designers and architects in the past, where they want to get all 100 percent, because they know that if you spend 15 percent of the effort now to deliver 85 percent of the value, you’re never going to spend the other 85 percent to deliver the last 15 percent.

Which may be a really awesome business decision, but you’ll never be 100 percent as good as it could be.

Roy:  Some of it is, building off Clayton’s response there, is, there are a lot of teams where if you say, “OK, fine, let’s just do X.”

You say, “OK, let’s do Y.” “OK, let’s do Z.” Then you say, “OK, let’s do A.”

Then they’re like, “We’re going to have to re‑evaluate the whole thing. If you would have told us up front that we had to do A, we would have totally built this in a different way. Now that you want A, we just have to throw away the last six months’ worth of work, and start all over, and if only you would’ve told us.”

Once they get trained for that it becomes, if I know anything I must disclose it now and tell you that you have to build it into the app, because if I disclose it later you may come back and tell me, “Oh man, we have to throw everything out and start again.”

Clayton:  By disclosing everything up front and insisting that it all gets done, the product owner is really trying to maximize his choice later on down the road. His ability to choose later on.

Roy:  They’re trying to mitigate their risk, I believe. If they disclose all that and say we need to do all of that, then they think they’re mitigating the risk of somebody coming back later and saying, “Oh, we can’t do that because you didn’t tell us.”

In reality, what they do is increase their risk exponentially, because they make it so it becomes almost impossible to deliver what they’re asking for.

Jade:  The cognitive load becomes much more to deal with and “grok” all of those additional features when they’re not needed.

Derek:  It sounds to me like then you’re going to try to build a system that’s overly architected just in case you have to build any of the number of features you’re told you have to support.

Roy:  One thing recently that clarified this a bit more for me was that we had a situation where we wanted to deliver some features that would have been nice to have a database.

Having a database was a non‑trivial thing, so we used the file‑system. We had a table with a row and a column in it. That’s all there was.

Derek:  A folder with files in it?

Roy:  Yeah. We had a folder with files. That was sufficiently complex for what we wanted to do. I think some people hear that, and they think, “What are you, f‑ing crazy? You can’t use the file‑system…”

[laughter]

Roy:  “…Use a database, that’s crazy.” What we understood was, right now, for what we’re trying to do, for this little slice, that’s what we need right now. We acknowledged that that is not a long‑term solution, but it’s going to be as long‑term as it needs to be for what we want to do with it.

Jade:  It was very simple to replace.

Roy:  Exactly.

Derek:  I think where this started to come and play for me was when we started to cross the chasm, so to speak, in doing a lot more mobile development.

So things that we thought were pretty trick and pretty sleek and pretty simple and pretty small started to fall down really quick when a customer would say, “hey by the way, I need an android version or an iPhone version of this.” and I was like, “oh shit, like dude like how in the, man!”

And so when it got to the point like “OK, let’s make everything like API and we’ll have the front end consumed of the web version consume that API and hey now we can have the iPhone version.”

Jade:  Anything can use this API

Derek:  API right like it started to like I think click a little bit more just even in that that you could kind of separate this concerns a little bit better.

Then you can start to say “OK how about make perhaps even smaller and smaller,” and keep slicing those so that they are easier and easier to replace, so when you do find something new you might not have to rewrite the whole system to do something. You might be able to rewrite a little piece of the system to do something which is a lot less risk and a lot easier to do.

Jade:  That’s kind of where [indecipherable 11:27] and I got into writing these micro‑applications that had very discreet functionality.

We were having trouble, even with that simplified view of things of just having an API and a web service that was still wasn’t good enough. There was still too much co‑mingling of functionality between different classes and you know, the abstractions were good enough.

We took a crazy stance and tried to work on like how can we build the smallest possible thing to do this one job, and then chain all of those things together as needed?

Roy:  I felt like that worked for those instances I am curious to try more places and see how well it runs across the board.

In that case it was a project that only ended up being a collection of five or six of these smaller apps, but when you start to build a more complex user experience where you have a whole store form or something where the user [indecipherable 12:24] component you try to keep all of those pieces separate. I wonder how well that’s going to play together.

Clayton:  I feel pretty confident in it from the next example like; pick any five UNIX commands. It could probably do a bunch of stuff. If you chose wisely.

Derek:  Yeah, It does fall down at certain point though. What I mean by that is, there’s a whole lot of things people do, they don’t do with Unix commands any more. You could use “set OK” and “grip” to do a whole lot of things.

Jade:  Everything

Derrck:  But you probably open up “vi” or “sublime” to do it instead because the interface is easier even though its [indecipherable 13:00] all mashed into an application than a whole lot more than those simple things.

I think there are this kind of. It is nice to assemble them small‑ly. Into small little apps that interact but when you have to chain too many interactions together, the complexity of remembering what and how to chain things starts to become cumbersome.

Clayton:  That and when there’s like a whole bunch of apps that you don’t even know existed.

Roy:  Yeah

Clayton:  So you start rewriting them yourself

Derek:  Yeah. What tends to happen is when you have things that have common things you start to see those assembled into other apps.

I would say that OK and grip get used within most editors the developers use today. Because they make sense to kind of bundle natively into an editor rather than a drop out to a shell and do them. I think the work that those things did and put in place are straight up stolen and re‑used inside of those editors.

Jade:  It’s like when we talked about, we built a simple app but at some point it became too complicated. It was simpler to take a different approach of writing smaller, more complicated apps. Think this is the contrary example of at some point that becomes absurd. The interactions are too complicated.

Derek:  Right.

Jade:  Now you find a simpler way to merge those things together.

Derek:  It goes back to; it’s always easier to get more complex.

If we’ve got the set the OK, the grip, and we need to put them all together like we know those things really well now and so we know how to assemble them into an interface or into certain things a lot better than if we would have tried to build those things as part of the bigger complicated thing to start with.

Jade:  I think that’s where some of the ideas around, like hexagonal design can come into play. Where you’re composing complex systems out of simpler modules and simpler pieces.

Clayton:  We’ve been talking a lot about in terms of software, but this same stuff applies to process things.

You can take the components and do them very well and you can build some sort of process that works and maybe it gets too big sometimes or maybe you decompose or whatever, but it’s not just whole scale, you know.

From a coding example, jumping straight into some massive java architecture thing and that’s the same thing as like what you’re going to get on the juror train and see if this mother app…

[laughter]

Clayton:  …Or it’s like trying to get a good user story. I am like “let’s try and get good at talking to each other as a team first.”

Derek:  Let’s get good at working together.

Jade:  Yeah, let’s try those things first and then you know, you can juror me to death.

Roy:  Hey I will see you next month

[music]

Presenter 1:  Is there something you would like to hear in the future episodes, head over to inagram.com/podcasts or you can suggest a topic or guest.

Presenter 2:  Looking for an easy way to stay up to date with the latest news, techniques and events in the agile community? Sign up today at agileweekly.com. It’s the best agile‑content delivered weekly for free.

The agile weekly podcast is brought to you by inagram technologies and recorded in gangplank studios in Chandler, Arizona.

For old episodes check out inagramtech.com or subscribe on iTunes.

Presenter 3:  Need help with your agile transition? Have a question and need to phone a friend? Try calling the agile hotline. It’s free, call 866‑2448656.

Email
Categories: Companies

Measuring Benefits of Software Development: Traditional vs. Agile

Scott W. Ambler - Agility@Scale - Mon, 04/14/2014 - 20:09

I was recently involved in an online discussion about how to calculate the benefits realized by software development teams.   As with most online discussions it quickly devolved into camps and the conversation didn’t progress much after that.  In this case there was what I would characterize as a traditional project camp and a much smaller agile/lean product camp.  Although each camp had interesting points, the important thing for me in the conversation was the wide cultural and experience gap between the people involved in the conversation.

The following diagram summarizes the main viewpoints and the differences between them.  The traditional project camp promoted a strategy where the potential return on investment (ROI) for a project would be calculated, a decision would be made to finance the project based (partly) on that ROI, the project would run, the solution delivered into production, and then at some point in the future the actual ROI would be calculated.  Everyone was a bit vague on how the actual ROI would be calculated, but they agreed that it could be done although would be driven by the context of the situation.  Of course several people pointed out that it rarely works that way.  Even if the potential ROI was initially calculated it would likely be based on wishful thinking and it would be incredibly unlikely that the actual ROI would be calculated once the solution was in production.  This is because few organizations are actually interested in investing the time to do so and some would even be afraid to do so.  Hence the planned and actual versions of the traditional strategy in the diagram.

image

The agile/lean camp had a very different vision.  Instead of investing in upfront ROI calculation, which would have required a fair bit of upfront requirements modelling and architectural modelling to get the information, the idea was that we should instead focus on a single feature or small change.  If this change made sense to the stakeholders then it would be implemented, typically on the order of days or weeks instead of months, and put quickly into production.  If your application is properly instrumented, which is becoming more and more common given the growing adoption of DevOps strategies, you can easily determine whether the addition of the new feature/change adds real value.

Cultural differences get in your way  

The traditional project camp certainly believed in their process.  In theory it sounded good, and I’m sure you could make it work, but in practice it was very fragile.  The long feedback cycle, potentially months if not years, pretty much doomed the traditional approach to measuring benefits of software development to failure. The initial ROI guesstimate was often a work of fiction and rarely would it be compared to actuals.  The cultural belief in bureaucracy motivated the traditional project camp to ignore the obvious challenges with their chosen approach.

The agile/lean camp also believed in their strategy.  In theory it works very well, and more and more organizations are clearly pulling this off in practice, but it does require great discipline and investment in your environment.  In particular, you need investment in modern development practices such as continuous integration (CI), continuous deployment (CD), and instrumented solutions (all important aspects of a disciplined agile DevOps strategy).  These are very good things to do anyway, it just so happens that they have an interesting side effect of making it easy (and inexpensive) to measure the actual benefits of changes to your software-based solutions.  The cultural belief in short feedback cycles, in taking a series of smaller steps instead of one large one, and in their ability to automate some potentially complex processes motivated the agile/lean camp to see the traditional camp as hopeless and part of the problem.  

Several people in the traditional project camp struggled to understand the agile/lean approach, which is certainly understandable given how different that vision is compared with traditional software development environments.  Sadly a few of the traditionalists chose to malign the agile/lean strategy instead of respectfully considering it.  They missed an excellent opportunity to learn and potentially improve their game.  Similarly the agilists started to tune out, dropping out of the conversation and forgoing the opportunity to help others see their point of view.  In short, each camp suffered from cultural challenges that prevented them from coherently discussing how to measure the benefits of software development efforts.

How Should You Measure the Effectiveness of Software Development?

Your measurement strategy should meet the following criteria:

  1. Measurements should be actioned.  Both the traditional and agile/lean strategies described above meet this criteria in theory.  However, because few organizations appear willing to calculate ROI after deployment as the traditional approach recommends, in practice the traditional strategy rarely meets this criteria.  It is important to note that I used the word actioned, not actionable.  Key difference.
  2. There must be positive value.  The total cost of taking a measure must be less than the total value of the improvement in decision making you gain.  I think that the traditional strategy falls down dramatically here, which is likely why most organizations don’t actually follow it in practice.  The agile/lean strategy can also fall down WRT this criterion but is much less likely to because the feedback cycle between creating the feature and measuring it is so short (and thus it is easier to identify the change in results to the actual change itself).
  3. The measures must reflect the situation you face.  There are many things you can measure that can give you insight into the ROI of your software development efforts.  Changes in sales levels, how often given screen or function is invoked, savings incurred from a new way of working, improved timeliness of information (and thereby potentially better decision making), customer retention, customer return rate, and many others.  What questions are important to you right now?  What measures can help provide insight into those questions?  It depends on the situation that you face, there are no hard and fast rules.  For a better understanding of complexity factors faced by teams, see The Software Development Context Framework.
  4. The measures should be difficult to game.  Once again, traditional falls down here.  ROI estimates are notoriously flakey because they require people to make guesses about costs, revenues, time frames, and other issues.  The measurements coming out of your instrumented applications are very difficult to game because they’re being generated as the result of doing your day-to-day business.  
  5. The strategy must be compatible with your organization.  Once again, this is a “it depends” type of situation.  Can you imagine trying to convince an agile team to adopt the traditional strategy, or vice versa?  Yes, you can choose to improve over time.  

Not surprisingly, I put a lot more faith in the agile/lean approach to measuring value.  Having said that, I do respect the traditional strategy as there are some situations where it may in fact work. Just not as many as traditional protagonists may believe.

Categories: Blogs, Companies

Discussions

Agile Zen - Tue, 01/21/2014 - 18:22

We have recently developed a new feature for having discussions about your board. This is an early release we want to get out to get some early feedback from our customers.

If you click Discuss at the top of your board, you will see all other members online at the present time and be able to chat with them.

Please let us know if you’d like to beta test this feature and help us polish it!

Categories: Companies

How to handle Tickets during Sprint Planning?

What is your real objective? To plan for maintenance hours or to ensure that your team is optimally utilized working on both user stories and defects while turning out quality code on a continuous basis, including defect fixes?

Categories: Companies

From Problem to Solution. Faster. - Part 1: Problem Interviews

ThoughtWorks Studios - Blog - Mon, 08/05/2013 - 20:23
Melissa Doerken

We’ve heard them both before. They’re givens in the tech world:

  • Understand your customer’s problem
  • Get early and continuous feedback

Sounds easy enough, but even seasoned software teams know both are much easier said than done, even with our growing awareness of the “build-measure-learn” methods promoted by lean-minded practitioners.

Thumbnail: 

read more

Categories: Companies

The Beginning of the End of Department Stores?

ThoughtWorks Studios - Blog - Fri, 08/02/2013 - 20:03
Robin Copland The retail world was abuzz this week with the news that Hudson's Bay (Hbc) is acquiring Saks Fifth Avenue. No surprise really; it was common knowledge that Saks was shopping around for a buyer with rumors in previous months that Nieman Marcus would make a great suitor. I imagine the reaction from most was almost a sense of relief that they finally found a buyer. This is, however, much more than a buyout story.   Thumbnail: 

read more

Categories: Companies

Monitoring the Build System - Part 2

ThoughtWorks Studios - Blog - Thu, 08/01/2013 - 18:03
Madhurranjan Mohaan

In Part 1 of our blog series on Monitoring the Build System, we walked through the challenges we faced and the ways we resolved them. In this blog, I'll discuss further details regarding our build system and the tools that we used.

Thumbnail: 

read more

Categories: Companies

Get better in 2 minutes: Part 3 - Mingle + Cycle Time Analytics

ThoughtWorks Studios - Blog - Fri, 07/26/2013 - 17:44
Ethan Teng

As part of our series on cycle time, we’ve covered what cycle time is, why it matters, and how you can use it to know if you're improving. In this video, you will see how Mingle + Cycle Time Analytics enables you to easily identify outliers and trends in your team's cycle time as well as spot bottlenecks in your team’s process.

Thumbnail: 

read more

Categories: Companies