Skip to content

Feed aggregator

Using Scrum Sprints for Pre-Project Planning

Scrum Expert - Wed, 06/25/2014 - 21:23
If the Agile Manifesto prefers responding to change over following a plan, it is not against planning. In this article, Raju Kidambi explains why it is important to use Scrum during the pre-project planning phase. The core of the article is the presentation of the concept of sprints PQRS to do the pre-project planning. This concept divides the pre-project planning activities in four sprints. The sprint “P” focuses on planning resources, high level scope, cost and schedule. The sprint “Q” focuses quality assurance related activities. The sprint “R” focuses on risk ...
Categories: Communities

Tasktop Gets $11 Million Financing - Wed, 06/25/2014 - 20:10
Tasktop Technologies has announced that it has closed a Series A round led by Austin Ventures, syndicated with Yaletown Venture Partners. The funding will help the company maximize the reach of its successful software lifecycle integration platform by expanding into new markets.
Categories: Communities

Perforce and Parasoft Collaborate on Development & Testing Platform - Wed, 06/25/2014 - 19:48
Perforce Software and Parasoft announced the integration of Parasoft's Development Testing Platform, which helps developers prevent software defects, with Perforce Swarm, the social coding solution from Perforce. Together, the two technologies streamline critical components of an enterprise& ...
Categories: Communities

How Rally Customers Helped Us Give Away $10K

Rally Agile Blog - Wed, 06/25/2014 - 18:22

Cynthia Koenig (center), Executive Director of Wello Water, and two team members express their appreciation for receiving the Citizen Engineer Award. Why put a suitcase on your head? Read on and RallyON!

At Rally we’re passionate about helping people see the impact of Agile -- which is why we made this the theme of our annual RallyON conference. But we’re also passionate about social impact -- which is why mobilizing people and organizations to be citizen engineers is the strategic focus of our corporate social responsibility program, Rally For Impact.

The Citizen Engineer Award

Six months ago, we launched the Rally For Impact Foundation with 1% equity from our IPO. We decided to award our first big grant at RallyON, and asked the nearly 500 people in attendance (many of them dedicated Rally customers) to select which organization should receive our $10,000 Citizen Engineer Award.

The four nonprofit organizations that participated in the Rally For Impact Scrimmage were these candidates:

Each organization explained how it would invest the $10K award, if selected. Projects ranged from crowdfunding campaigns for doctors working in medically underserved parts of the world, to delivering clean water more efficiently to people in rural India, to converting a vast document-management system into an online portal for sharing civil engineering project information with other organizations globally.

Attendees then used the RallyON 2014 conference app on their handheld devices to vote for one of the four social impact organizations.

RallyON keynote speaker Bernard Amadei made an inspiring citizen engineer call to action in his presentation, Technology With A Human Face (slides), then announced the winner at the conference’s closing award ceremony. Reflecting on the experience, Rally founder and CTO, Ryan Martens said,

"Many people in my life have contributed to my passion for citizen engineers, leading me to develop a deep belief that my fellow engineers and I must use our skills to benefit people and the planet. Bernard Amadei was one of those people. As my undergraduate professor in 1985, he taught and inspired me at a young age. To stand beside him on stage at RallyON, almost 30 years later, with nearly 500 Rally customers in the audience as we announced the $10,000 Citizen Engineer Award was an amazing experience for me both personally and professionally."

Bernard Amadei, founder of Engineers Without Borders, presents the Citizen Engineer Award at RallyON as Rally founder and CTO, Ryan Martens, looks on.

And the Winner Is ...

Wello is a startup nonprofit that “... develops and distributes disruptive products and services that efficiently deliver clean water to a thirsty world.” Using Wello’s flagship innovation, the WaterWheel, women can transport three to five times the amount of water compared to traditional methods -- in a single trip.

“Every day, hundreds of millions of women and girls walk long distances, struggling to collect enough water to meet their families’ basic needs. By reframing the water crisis as an opportunity, Wello has reinvented the wheel and developed an innovative business model that empowers individuals to use the WaterWheel as an income-generating tool to lift their families out of poverty.” -- Cynthia Koenig, Wello Executive Director

Rally employee Christine Hudson demonstrating a marketing idea generated at the Rally For Impact Scrimmage.

People need at least five gallons of water each day to stay healthy and hydrated. Five gallons equals 42 pounds, which is the typical weight of a checked bag for an airline flight. Women and girls in rural India traditionally carry this weight on their heads, every day (video), for each family member. With the WaterWheel, they can now transport 50 liters at once – between three and five times the amount of water possible as compared to traditional methods.

​In the 18 months since Wello launched in India, it has co-created the product design, launched pilot projects with more than 1,000 consumers, and measured the impact of its invention. By using the WaterWheel, families are benefiting from an additional two hours of productivity, higher incomes, better school attendance, and improved health.

Wello won the $10,000 Citizen Engineer Award thanks to its WaterWheel, which helps women transport three to five times the amount of water -- compared to traditional methods -- in a single trip.

How Wello Will Invest Its $10K

Wello is currently on a roll -- fielding order inquiries from around the world and investing in a scalable manufacturing technique to meet demand. The nonprofit has raised half of the $20,000 it needs to fabricate a blow-mold tool. Thanks to the $10,000 Rally For Impact grant, Wello will be able to produce one million WaterWheels and reach an estimated six million people.

“It's a huge honor to have been selected from among a group of outstanding organizations to receive the Citizen Engineer Award. This funding also comes at a pivotal time. Wello is scaling production to meet demand and this award will enable us to make an investment in tooling to produce our next-generation WaterWheel. Thank you, Rally!” -- Cynthia Koenig, Wello executive director

  Geri Mitchell-Brown
Categories: Companies

Survey of two large MVC projects

Jimmy Bogard - Wed, 06/25/2014 - 17:17

A large-ish MVC project in which I led the architecture is hitting a milestone of 12 months in development (though released to production for some months now). It’s a similar project to the one where AutoMapper came from, but this time targeting a more focused domain, and subject of the How We Do MVC post.

Much of the patterns discussed come from a certain context, especially on optimizations I look at for accelerating delivery that don’t necessarily apply to other systems. Some comparison stats between these two projects:

Project A

  • ~6 years of continuous development at various pace
  • Over 100 deployments to customers statewide
  • 352 Controllers
  • 1079 Actions
  • 3 actions/controller

Project B

  • 12 months of continuous development at continuous pace
  • At least one deployment to a customer, a few more planned this year, then dozens the next
  • 71 Controllers
  • 534 Actions
  • 7.5 actions/controller

So while B only has 20% of the controllers of A, it has half the actions. This is for a couple of reasons:

  • 6 years ago AJAX was difficult for accessibility. Not the case any more, so AJAX plays a much bigger role
  • Task-based UIs mean a lot more contextual actions take place on one screen, depending a large number of factors

All these “put XYZ” on a diet talks, preferring slices over layers, and in general wanting new features to only add classes and files and not modify them is because of the scope of projects I generally deal with. I have to come up with tools and techniques to address design challenges of this scope, so tools like AutoMapper, the mediator pattern, feature folders, HTML conventions, slices over layers, no convoluted project structure and so on are critical to allow this sort of project to continue at a pace without slowing down under its own weight.

In this project, we had no repositories. No layered project structure. No abstractions over dependencies. No vegetable-based architectures. The last 12 months had roughly 250 working days, which averages out to a new controller every 3.5 days and a little over 2 new controller actions every single day. That sort of pace can only come from a laser focus on highly cohesive code, where each new feature only added requisite classes for feature where pieces differed, and allowing conventions to fill in mundane details that we intended to be consistent site-wide.

I’ve already covered our designs in our controllers, next, I’ll pick up the conventional HTML post that allowed us to create a highly streamlined process for building out our views (and how we extended this concept to client-side templates).

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Five links on Agile and Projects

I’m more interested in successful projects than I am in the name of the process.






I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!

Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: Please follow @agilequote for more quotes.

Categories: Blogs

Do You Need to Create Virtual Teams with Freelancers?

Johanna Rothman - Wed, 06/25/2014 - 14:30

Have you seen Esther Schindler’s great article yet? Creating High-Performance Virtual Teams of Freelancers and Contractors.

Here’s the blurb:

Plenty has been written about telecommuting for employees: how to encourage productivity, build a sense of “we’re all in this together,” and the logistics (such as tools and business processes) that streamline a telework lifestyle. But what about when your team is neither employees nor on-site? That gives any project manager extra challenges.

Lots of good tips.


Categories: Blogs

Cape Town July 2014 – Building a great product

Scrum User Group of South Africa - Wed, 06/25/2014 - 12:58
SUGSA’s monthly Cape Town gathering will be held on 3 July at Allan Gray. See event for more details.
Categories: Communities

How Agile accelerates your business

Xebia Blog - Wed, 06/25/2014 - 11:11

This drawing explains how agility accelerates your business. It is free to use and distribute. Should you have any questions regarding the subjects mentioned, feel free to get in touch.

Categories: Companies

Scrum Day Europe, Amsterdam, Netherlands, July 3 2014

Scrum Expert - Wed, 06/25/2014 - 09:50
Scrum Day Europe is a one-day conference dedicated to Scrum. The 2014 edition of this conference dedicated to agile project management will take place in Amsterdam and will features expert speakers like Ken Schwaber. This is a main event for all European Scrum practitioners. In the agenda up you can find topics like “Led Zepelin Scaling Agility”, “Agile Transformation of a 20,000 Person Company – a Long Term Journey”, “Serious Play on the Path to Agility”, “Using Lean UX to build the right things”, “Product Owner Value Game” or “Agile Myth ...
Categories: Communities

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

Goodbye From the Bobs

Agilitrix - Michael Sahota - Tue, 06/24/2014 - 21:33

(This is goodbye letter shared with the department Paul Heidema and I have been working with for the last few months).

Hi All,

This is a goodbye letter since we are at the end of the main part of project Cocoon.

Why the Bobs?
Someone identified us early on as kinda like The Bobs from Office Space. We like that and think this is really funny.

We hope by now that you see us differently.

We are not here for Agile
If this hasn’t been clear, we are to help you succeed with project Cocoon – which is about re-inventing your department. It’s not about being Agile or using Agile practices. Sure that helps support the goals of Cocoon, but Agile stopped being a goal in April. The goal is helping everyone here be fully engaged and unleashing talent.

Are we Done?
We all wish we had more time. But we don’t. We have made an explicit decision with your leadership team to balance work between tactical, strategic and cultural to best move the needle forward on the Cocoon Vision. We wish we had more time to work with teams, but that would have taken away from sustainable change.

Lasting Change Takes Time
Real and lasting change takes time. It takes everyone working daily to make healthier and more loving interactions.

So sorry, if you were expecting a big TA-DA celebration of success, you are not going to see one. There is a lot of hard work ahead and it takes time to turn the ship around. This is an all-hands type of change.

Keeping in Contact
If you want to stay in touch, you are welcome to connect with us via LinkedIn or email.

When will we be Back?
Paul and Michael will be back together in late August and Michael will be back in Sept/Oct to provide follow-up support.

Happy & Sad
We are so happy to have been able to work with all of you. We are proud of all that has been achieved together. And we are sad to go as we have enjoyed traveling on this road together with you.

You are in good hands
I am glad that you are in good hands. You have a very courageous management team – they are working on themselves first so they can lead by example. And starting to tackle difficult decisions. And of course Corey who has grown so much through this process and enabled all of this to unfold the way it has.


Michael & Paul

Photo: In our support center with Corey

The Bobs

Related posts:

  1. Agile is NOT the Goal (Workshop) Here is how to run a one hour workshop turn...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

Case Studies: Software Systems Failure

Agile Complexification Inverter - Tue, 06/24/2014 - 19:01
Software nightmare stories are very common - but one thing I've learned by listening to these stories over the years is the technologist must be optimist at heart.  Why - because they deal constantly with tons of failure.  And out of those failures they create innovative disruptive new sectors of the world economy (sometimes, case in point the Apple Newton and then the iPod and iPhone).

Let's look at a few case studies:

Time has just published a look at the Obama Healthcare rescue team.  Code Red by Steven Brill

"What were the tech problems?  Where they beyond repair? Nothing I saw was beyond repair.  Yes, it was messed up.  Software wasn't built to talk to other software, stuff like that.  A lot of that,"  Abbott continues, "was because they had made the most basic mistake you can ever make.  The government is not used to shipping products to consumers.  You never open a service like this to everyone at once.  You open it in small concentric circles and expand" -- such as one state first, then a few more -- "so you can watch it, fix it and scale it."
What Abbott could not find, however, was leadership.  He says that to this day he cannot figure out who was supposed to have been in charge of the launch."Or take a look at an Agile/Scrum successful rescue -- the FBI Sentinel case management system.
FBI's Sentinel Project: 5 Lessons Learned by InformationWeek's John FoleyCase Study of a Difficult Federal Government Scrum Project: FBI Sentinel by Michael JamesDoD Goes Agile by Jeff Sutherland DOJ's Report on Sentinel Project by Inspector General - Dec. 2011How the FBI Proves Agile Works for Gov. Agencies by CIO's Jason Bloomberg"Wait, agile rescued a huge money-pit fiasco of a government project? You mean, iterative, skunkworks, put-the-customer-on-the-team, forget-the-plan agile? You betcha. Agile turned out to be the hero in the tights and cape, coming to save the day."
Effective Practices and Federal Challenges in Applying Agile Methods  GAO-12-681: Published: Jul 27, 2012What can one make from failure? Well, author John Kotter of the airport best seller's shelf (Leading Change) created his 8 step model from investigating why companies consistently fail to institute the desired organizational changes that they assumed were mission critical. His conclusion, if they had just done eight things well then the organizational change would have succeeded.
So what can we learn from two of the US governments most recent software project failures?  I think it can be summarized in one phrase - the Big Bang model only works for universes (or God).  The rest of us better learn how to iterate, grow, and evolve systems.

See Also:
Before Scaling up, Consider...
Agile Succeeds 3X more than Waterfall - CHAOS Report 2011 - MountainGoat Software
ObjectMentor success stories:
    Sabre takes extreme measures - ComputerWorld

Categories: Blogs

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.


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.


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

Better Agile Meetings Through Questions

BigVisible Solutions :: An Agile Company - Tue, 06/24/2014 - 17:07

If you happen to be in a meeting with a written objective and agenda, the agenda will have items like “review the plan”. It sounds reasonable. But it is, in fact, very likely to waste your time.

Why? Better Mtgs Thru Questions_BF

Simply, there is no definition of success, so you could talk about the plan for hours and still not accomplish whatever goal was underlying the agenda item. What does success look like for “review the plan”? Do you just put it up on the screen and everyone looks at it? Do you review every task in minute detail? If you define meeting agenda items using questions that specify success, that will help you get
out of this problem and have more effective meetings.

Let’s translate “review the plan” into a few example questions to show you what I mean. I’ve included the meeting objective which is another key piece of meeting success.

Objective: Have a plan that ensures we’ll have enough stories for our team to start work on July 1

  • Will the current plan enable us to have two sprints worth of user stories ready for building by the team by July 1?
  • If no, what do we need to change in the plan to meet that objective?
  • When can we get together as a team to work for an uninterrupted block of time to focus on this work?
  • If the answer is “yes” to the first question, you can move onto the third. When the questions are answered and the objective met, you end the meeting. If the meeting gets off track you can ask “is this discussion pertinent to the question we’re trying to answer?”

    Like any tip for better living (eat more green leafy vegetables) practicing this is harder than reading about it. Try it for two weeks and see what you think.
    (Thanks to David Spann, who introduced me to this idea in his wonderful meeting facilitation course years ago.)

    Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.


    The post Better Agile Meetings Through Questions appeared first on BigVisible Solutions.

Categories: Companies

LeadingAgile is Hiring Agile Coaches and Consultants

Leading Agile - Mike Cottmeyer - Tue, 06/24/2014 - 13:57

Hey Folks… I’ve never posted anything like this before, but I wanted to let you guys know we are growing and looking for a few top-notch coaches to hire over the next several months. If you are interested, or know anyone that is, please give us a shout.

That said, let me give you an idea of what we are looking for in our ideal agile coach.

1. Our coaches come from a variety of backgrounds so there isn’t really one profile that fits for us. We have folks that have been senior executives in large companies as well as executives in startups. We have people that have started and run their own businesses. We have people that come from a more traditional training and coaching background and we have people with a more traditional management consulting background. The people that tend to work out best for us bring a passion for agile, pragmatism about what agile looks like during a transformation, and a sincere passion for helping people and organizations get better at what they do.

2. As you might expect, you need to be an expert in agile. You should be steeped in the literature and extremely knowledgeable about the entire family of methods. You should be conversant in Scrum and XP as well as Kanban and SAFe. You should know about Crystal, DSDM, FDD, and Lean and where they fit into the body of knowledge. You should have a background applying a wide variety of agile methods in complex environments. You should have the conviction to stand firm on principles but a willingness blend and bend approaches as necessary to help our clients be successful.

3. We need you to be confident and self-assured yet humble with a willingness to learn. While we are not a training company, it would help if you were a gifted trainer full of anecdotes and stories about agile teams you’ve worked with and transformations you’ve lead. You need to be able to hold a room for several days and connect with all levels of an organization. You should be equally comfortable working with a room full of executives as you are with a room full of developers. You’ll often need the ability to speak developer to the business people and business to the developer people. A broad, inclusive perspective is essential.

4.You’ll need to have a strong degree of emotional and social intelligence and have the ability to read a room and adapt your approach to meet the unique needs of the people you are working with. You should have excellent problem solving skills and the cognitive resources to develop customized solutions on the fly, brainstorming ideas with senior leaders in unfamiliar and unique problem domains. You need to be able to work and collaborate with an expert team of coaches, every one of them with strong opinions and unique points of view, and craft solutions that work in the best interests of our clients.

While we strive to find local work for our coaches, if you are not in Atlanta, Washington DC, Orlando, Denver, New York, New Jersey, Los Angeles or San Francisco… you should expect to travel nearly 100%. Local work isn’t impossible to find in other areas, I just wouldn’t count on it. These are the areas where we currently have the most traction or an established client base. That said, even if you are working in your home town, some travel is pretty much inevitable.

You should know that a big part of what we do is probably less coaching and more management consulting. If you are familiar with our approach, you’ll know that we take a pretty hard stance that we have to define a structure, governance, and metrics model as precursor to leading a transformation. We are pretty prescriptive with many organizations, especially early in the process, about how we are going to implement agile. In the complex organizations where we work, playing soft will get us fired. We walk in with a point of view and a plan and a strategy for helping get the transformation started.

In return, we offer a pretty unique environment to work and a very interesting compensation plan.

We are totally distributed but operate in a series of small independent teams we call tribes. Each tribe has all the roles necessary to deliver an account. While you might be flying solo on any particular engagement, you have the support of a complete cross-functional team to share the load. Within the LeadingAgile transformation framework, your tribe has a ton of autonomy to do anything necessary to deliver for the client… you can even ditch the framework if you have to. If we find our approach stops working for us or our clients, we’ll change it. All policy and process is owned by the team we make changes using an open source/committer model.

We are committed to full transparency when it comes to salary, margin, and operating costs, and such within our organization.

We are in the process of moving all our coaches to the same base salary. Each coach has the opportunity to earn an extra 20% of their salary if the company meets certain delivery targets and its a whole team incentive. We are working on a model that can create significant upside for our coaches for certain kinds of sales and marketing activities and we are building a stock option and stock purchase program so everyone has a stake. On occasion we’ve been able to craft unique compensation plans to accommodate special situations where a coach has an established pipeline and/or a proven track record of business development success.

We are definitely a work-in-process and quite often operating way above our WIP limits. If you’re interested in driving meaningful change in large complex organizations, and you want to work for a unique, fast-paced, and innovative early stage growth company… hit us up on the Contact Us page, we’d love to talk. Please make sure to have a resume handy as well as links to anything you’ve posted recently that will give us an idea of what you’re passionate about and how you think.

The post LeadingAgile is Hiring Agile Coaches and Consultants appeared first on LeadingAgile.

Categories: Blogs

A technique to help Prioritise your Backlog

Growing Agile - Tue, 06/24/2014 - 10:00

As a Product Owner do you ever feel that you have too much work and not enough capacity, or have too many stakeholders yelling for their items to be done first? Do you never have time to tackle technical debt or innovation because the head of sales keeps demanding new features?

Prioritising items correctly is one of the difficulties we often see with backlogs. Having a correctly prioritised backlog is valuable though. It ensures that your team is working on the most important items for the business and that your product is headed in the right direction. The most important job you have as a Product Owner is deciding how best to use your team’s capacity.

We have a technique that we teach Product Owners to help prioritise across different stakeholders. The quadrant below shows one way of representing all the possible work that needs to be done on your backlog against 2 axes: time and who the work helps most. In our experience it is easier to get your stakeholders to make an agreement that features to support new customer should only take up 50% of your capacity (for example), than that a particular technical debt item is more important that a particular customer feature. Once you have an agreement of what percentage of capacity to spend on each area (total should be 100%), then you can get stakeholders for each quadrant to prioritise what is the most important way to spend their percentage of the capacity.

PrioritisationSlide A technique to help Prioritise your Backlog

Past and Business (Q1) Here past refers to existing features, or existing clients. Business stakeholders refers to items customers would care about. Items that fall into this quadrant are usually called support items. This might be bug fixes that have been logged by customers, or minor enhancements to an existing feature to make life easier for an existing customer. Items in this quadrant won’t get you new customers, but they will impact on the retention and happiness of existing customers. Also this quadrant is often funded by maintenance and support contracts, so it can in fact be a revenue generating quadrant.

Future and Business (Q2) This quadrant is often the only one people focus on, especially if there is a big drive to get new customers. Items in this quadrant would be anything to help get more customers in future. It could be anything from new features, to scaling, to adding additional platform support for a new type of user.

Past and Technical (Q3) This is an often neglected quadrant. Essentially it is items that exist which impact the technical team. Technical debt is a good example. For example, one feature might be badly written and therefore be very fragile; resulting in bugs each time the team work on this feature. Items here don’t usually bring in revenue, but if selected well they can be great cost savers. Another example in this quadrant might be something that saves the support team a lot of time. For example if your support staff have to debug complex issues, adding additional logging information might be something that will help them reduce the time they spend here.

Future and Technical (Q4) This quadrant is a forward looking quadrant with a technical slant. Often architects can advise on ideas for this quadrant. Potentially a new piece of technology is available that will simplify your product significantly. Other items might be upgrades to existing technology stacks, before the technology you use becomes redundant. For example, upgrading to the latest version of Java. These items can sometimes bring in revenue, because they appeal to customers, but usually these are cost savers, the new technology should make development easier for your team.

BookMB A technique to help Prioritise your BacklogThis is a technique we use in our book “Growing Agile: A Coach’s Guide to Mastering Backlogs”. We have many workshops you can run with your team and Product Owners to help them.

Categories: Companies

Humans suck at statistics - how agile velocity leads managers astray

Software Development Today - Vasco Duarte - Tue, 06/24/2014 - 05:00

Humans are highly optimized for quick decision making. The so-called System 1 that Kahneman refers to in his book "Thinking fast, thinking slow". One specific area of weakness for the average human is understanding statistics. A very simple exercise to review this is the coin-toss simulation.

Humans are highly optimized for quick decision making.

Get two people to run this experiment (or one computer and one person if you are low on humans :). One person throws a coin in the air and notes down the results. For each "heads" the person adds one to the total; for each "tails" the person subtracts one from the total. Then she graphs the total as it evolves with each throw.

The second person simulates the coin-toss by writing down "heads" or "tails" and adding/subtracting to the totals. Leave the room while the two players run their exercise and then come back after they have completed 100 throws.

Look at the graph that each person produced, can you detect which one was created by the real coin, which was "imagined"? Test your knowledge by looking at the graph below (don't peak at the solution at the end of the post). Which of these lines was generated by a human, and which by a pseudo-random process (computer simulation)?

One common characteristic in this exercise is that the real random walk, which was produced by actually throwing a coin in the air, is often more repetitive than the one simulated by the player. For example, the coin may generate a sequence of several consecutive heads or tails throws. No human (except you, after reading this) would do that because it would not "feel" random. We, humans, are bad at creating randomness and understanding the consequences of randomness. This is because we are trained to see meaning and a theory behind everything.

Take the velocity of the team. Did it go up in the latest sprint? Surely they are getting better! Or, it's the new person that joined the team, they are already having an effect! In the worst case, if the velocity goes down in one sprint, we are running around like crazy trying to solve a "problem" that prevented the team from delivering more.

The fact is that a team's velocity is affected by many variables, and its variation is not predictable. However, and this is the most important, velocity will reliably vary over time. Or, in other words, it is predictable that the velocity will vary up and down with time.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project. For us as managers it is more important to understand what that throughput capability is, rather than to guess frantically at what might have caused a "dip" or a "peak" in the project's delivery rate.

The velocity of a team will vary over time, but around a set of values that are the actual "throughput capability" of that team or project.

When you look at a graph of a team's velocity don't ask "what made the velocity dip/peak?", ask rather: "based on this data, what is the capability of the team?". This second question will help you understand what your team is capable of delivering over a long period of time and will help you manage the scope and release date for your project.

The important question for your project is not, "how can we improve velocity?" The important question is: "is the velocity of the team reliable?"

Picture credit: John Hammink, follow him on twitter

Solution to the question above: The black line is the one generated by a pseudo-random simulation in a computer. The human generated line is more "regular", because humans expect that random processes "average out". Indeed that's the theory. But not the the reality. Humans are notoriously bad at distinguishing real randomness from what we believe is random, but isn't.

As you know I've been writing about #NoEstimates regularly on this blog. But I also send more information about #NoEstimates and how I use it in practice to my list. If you want to know more about how I use #NoEstimates, sign up to my #NoEstimates list. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to our mailing list* indicates required Email Address * First Name Last Name

Categories: Blogs

The Chaos of Leadership or the Leadership of Chaos

TV Agile - Mon, 06/23/2014 - 18:45
Our world suffers from terminal normality. Our world also suffers from too much false expertise, wrong answers, manipulative influence, and bad advice. In this chaos we are taught to make our way to be a success! And we get skewered. Frequently. We’re told to lead, that leadership is influence but those in power, i.e., The […]
Categories: Blogs

Knowledge Sharing

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