I find it fascinating that many people complain about organizational behaviors, yet nothing changes. Want to be more agile? Change something. Let’s take meetings, for example. It seems that most people complain about meetings.
Here are some of the most common complaints:
- There no clear purpose or objective is offered.
- No meeting agenda or timeline is published.
- Attendees tend to ramble or repeat previous comments.
- Meetings fail to inspire or motivate and nothing new is learned.
- Little team interaction or collaboration takes place.
- There are no specific action items or take-away points.
- They start late and wander aimlessly, only to end late.
- They are too long for the value generated, if any.
- Information is repeated for late arrivals making it advantageous to be late.
- Primary presenters are unprepared, boring, redundant, and generally weak.
That’s a pretty serious indictment of meetings across the corporate world. I’m sure you can relate to more than one of those reasons. So, if most of us hate meetings so much, why do they continue to dominate corporate cultures?
Many managers actually like meetings. Meetings give managers an opportunity to connect with a group in far less time than trying to meet with everyone one-on-one. Problems arise when the managers are ill-prepared and focused on their needs, but not the needs of the group.
Meetings are also ingrained as a critical element in some business processes. You often see a business process with a few steps followed by ‘stop and call a meeting’ … a few more steps and ‘stop and call another meeting’ … etc. Calling a meeting may be the no-brainer approach but is it really optimal given all of the technology we have today?
What’s the solution?
If you look closely at the reasons above, you’ll note that people don’t necessarily hate meetings. They hate how meetings are conducted. This is a business process problem that can be solved.
Start small. Ask people who schedule many meetings why they believe so many meetings are needed. Help them fix their meetings — make them shorter, less frequent, more focused, less redundant, etc. Also help them explore alternatives such as using social media tools to replace some meetings.
Whenever you feel compelled to call a meeting, lead by example. Address the issues above, ask for feedback, and suggest that others should follow a similar approach. Consider stand-up meetings to help keep them short and emphasize the importance of time. Schedule your meetings for 30 minutes whenever you can and never go beyond 50 minutes. People need an opportunity to pack up and head off to their next meetings. (College courses rarely start and end on the hour. There’s a reason for that!)
We won’t be able to cure the scourge of meetings anytime soon. They are too ingrained in our corporate cultures. But small steps can make a difference.
The same rule applies to any group behavior you’d like to change. Start small. Trying to change too much, too fast is too hard. Slow down and you’ll reach your goal sooner. Be agile!
Back in the old days, around 1999, there was a widespread opinion that the Internet and more specifically, the World Wide Web, would change everything. They have — but that was only the beginning. The real game changer is mobile computing.
Smartphones and tablets are revolutionizing how we behave and how we do things. There is a growing expectation that anything requiring a computer can be done from anywhere. This trend is in turn fueling the drive toward agile software development approaches like Scrum, Kanban, Lean and XP.
Why? It’s simple really. Mobile technologies and capabilities are changing so fast that traditional “plan now and implement later” approaches simply can’t work. By the time the team gets around to implementing the planned solution, the landscape will have changed.
Every enterprise software application has to operate in a mobile environment. You can no longer assume that the end user will be in a cubicle running the software on a desktop or laptop. Those days are over.
The future is:
- Smartphones (think iPhone, Android, Windows Mobile, Blackberry, etc)
- Tablets (think iPad, Android, Windows 8, etc.)
- Phablets (smartphone/tablet hybrid devices)
- Mobile Broadband (WiFi, 3G and LTE)
You can no longer assume:
- Desktop Systems (massive displays, fast processors, local storage, etc.)
- Laptops/Notebooks (physical keyboards, local storage, local ports, etc.)
- High-Speed Networks (wired networks, reliable connections, 10GB/100GB ethernet, etc.)
Mobility changes everything.
Those companies that get it will prosper. Those that don’t will perish.
If your software product backlog contains mobile functionality, get it into the sprint backlog or Kanban queue now. You need to start learning soon, before your team gets left behind. If the product backlog doesn’t mention mobile, looking for another project to work on may be your best option. Why would you want to work on a project that is likely to deliver a product that the marketplace leaves behind?
I’m sure that some people reading this will argue that their project is an exception — it doesn’t need to support mobility. That assumption is likely to be based on what they know and what they observe today. Yet, the mobile landscape is changing at a furious pace. There is simply no way to know what it will look like in a year or two.
Faced with this level of uncertainty, the only viable option is to embrace agile techniques and begin including mobile devices and technologies in your roadmap and backlog. Don’t wait. The marketplace isn’t.
In wrapping up this 12-post series about enterprise agile development, I feel compelled to touch upon a widespread practice in large firms. That is, developers assigned to work on more than one project at a time. They are typically told something like “…spend X% of your time on Project A, Y% on Project B and Z% on Project C”. They are rarely required to track actual hours except in the case of contractual work for paying clients.
Note that percentage of time allocated doesn’t map to project priority. For example, I might be told to spend only 10% of my time on Project A, yet the project could be mission-critical. It simply doesn’t need much of my expertise at this time.
Most developers would prefer to allocate a fixed time period each week for each project. So, I might devote Monday morning to Project A, the afternoon and all day Tuesday to Project B and the rest of the week to project C. This makes time management easy and provides a fixed frame of reference.
Unfortunately, fixed blocks of time almost never work. What if each project has a daily stand-up meeting and I’m expected to attend all three? (Let’s assume they don’t occur at the same time!) There’s also the major problem of interruptions. I can’t simply say, “Hey it’s Tuesday. I’m not working on your project today.”
The Multitasking Myth
Senior contributors are often expected to multitask but let’s face facts. Humans cannot truly multitask. Most of us are fairly good at switching contexts thus giving the appearance that we are working on more than one project at a time. In reality, each context switch eats up time as we mentally ‘file’ away the current project and open the ‘file’ for the next project. The switching process can take anywhere from a few minutes to half an hour depending on the complexity of the situations.
The practice of assigning multiple projects to developers is not going away anytime soon, particularly in the lean corporate environments of today. Here are a few ideas for dealing with it.
As a manager…
- Re-examine your list of projects. Cancel whatever you can or at the very least, put entire projects in the project backlog. Don’t fall into the trap of assigning someone to a project just to keep up appearances by attempting to show minimal progress.
- Eliminate unnecessary or redundant activities. Keep workflows simple for the developers and valuable to the company.
- To reduce interruptions, consider assigning a dedicated production support person/group to handle production problems. This assignment could be done in a round-robin fashion within the organization to balance the support workload.
As a developer…
- Try your best to allocate blocks of time to each project. The bigger the block, the more productive you’ll be.
- If you know what you’ll be working on over the next few days, try to batch similar activities across projects. The context switching will be easier.
- When interrupted, ask if the issue can wait until you have a chance to finish the current activity or at least bargain for time to get to a natural stopping point.
- Avoid having hours per week per project determine your activities. Always try to finish something before switching. Seek to balance out the hours per project over 2-4 weeks.
Finally, if there’s a crisis and you need to drop everything for several hours or a few days, communicate. Let your Project Managers, Scrum Masters, etc. know what’s happening. They’ll appreciate the notice and will be more likely to give you some leeway.
My examination of enterprise agile development based on the article I wrote for the Tools Journal called “10 Tips for Succeeding with Enterprise Agile Development” is nearly complete. Let’s talk about delivery dates…deadlines…schedules…drop-dead dates.
Meeting dates is important. Let me repeat that — “Meeting dates is important.”
Some agile development practitioners seem to believe that being agile means not committing to software delivery dates. They say something like, “The software will be ready when it’s ready”. That’s wrong! The software must be ‘done’ by the due date.
No one can run a successful business amidst uncertainty and doubt, particularly an enterprise-scale business. Customers, investors and partners need to know when a product or service will be available. It may be a completely new service or an upgraded product. Either way, we all want to know when it will arrive!
It’s vitally important for companies to set delivery dates and hold them firmly. Too often, I see companies set software end dates only to move them when it becomes painfully obvious that there’s no way to deliver as scheduled. It’s quite common to see dates moved several times before the software arrives — or the project gets canceled. Wrong move!
Meeting dates is important.
- Set realistic delivery dates that the development team has helped set and has committed to meeting.
- Do not move the end dates.
Everyone in the company needs to get the message that dates are important and they will not be moved. Once that message sinks in, behaviors will change and people will come together in a coordinated effort to deliver on time.
Now the bad news…
The business will NOT get everything it wants. I said dates have to be met but I never said anything about delivering every feature and function in the requirements document or user story backlog. There needs to be flexibility somewhere and it belongs in the software requirements.
The business needs to prioritize and sequence the software requirements or backlog. If the schedule has been vetted by the team, the most important items will get done by the deadline. Anything that doesn’t make the cutoff, will get rolled into future software updates.
A critical success factor is having the development team estimate the work effort and buy into the delivery dates. The traditional approach of having senior managers define the requirements, pick an arbitrary end date, then force it upon the developers is a guaranteed disaster. Stop doing that!
This collaborative approach will require a cultural change at many companies. It’s a change that’s well worth the effort.
Good agile software development teams:
- Expect mistakes.
- Encourage failure.
- Fail fast.
You’re probably thinking something like “This guy is nuts” (or perhaps something not so nice). Maybe I am, but I learn fast. Part of being agile is a willingness to take small risks. We all want our projects to succeed but face it, nothing ever goes perfectly. Mistakes happen. Accept it.
There’s a world of difference between taking small risks that may result in small mistakes versus taking big risks that could endanger an entire project. Here are a few examples:
1a) Small Risk: Committing to finishing a small set of user stories by a target date.
1b) Big Risk: Agreeing to an arbitrary corporate deadline for an entire project without understanding the details.
2a) Small Risk: Trying out a technique on the stakeholders and users before embarking on a major software change.
2b) Big Risk: Assuming that the business representatives know what they want and spending three months building it.
3a) Small Risk: Trying out a new algorithm in a test environment.
3b) Big Risk: Deploying a new algorithm into production without adequate planning or testing.
Each of the “a” items includes a small risk. If something goes wrong, minimal time is wasted. Perhaps more importantly, something will be learned. That something will help the team during the remainder of the project. There will be time to regroup and recover.
Each of the “b” items includes a big risk. If something goes wrong, the project could fail. Even if the team can regroup, the amount of time and money wasted may never be recovered.
Don’t expect perfection.
Every mistake results in a bad outcome. No one likes to make mistakes. No one wants to fail. Yet, nobody is perfect so mistakes will happen. We can take steps to minimize them but we can’t entirely avoid them. Agile development teams recognize these truths.
Some software teams spend an enormous amount of time writing project plans and conducting risk assessments. They operate on the belief that with enough planning and analysis, the risks can be mitigated and projects can succeed. While there’s some truth in that, it’s also true that such approaches are costly in terms of time.
It’s not just the additional development time. They are costly in the marketplace. The cost manifests itself in lost business, lost customers, and lost opportunities.
- “Expect mistakes” means letting people take small risks. It doesn’t mean repeating the same mistakes!
- “Encourage failure” means allowing the team to experiment and learn. It doesn’t mean failing to deliver as promised!
- “Fail fast” means testing assumptions early in the project. It doesn’t mean having the entire project go down in flames!
These can be tough concepts for larger enterprises to grasp. Many such firms have an inherent fear of failure caused by the tendency to assign blame every time something goes wrong. Stop blaming and start learning. You’ll be more successful.
When rolling out an enterprise agile approach like Scrum, Kanban or XP, you’ll be tempted to treat all development teams the same and to synchronize them at the same competency level. That won’t work.
There are many factors that impact a team’s ability to transition to agile software development. Consider these:
- Some people will be reluctant to change. When the reluctant ones are senior members of a team, they are in a position to hold back the entire team effort.
- The opposite is also a problem. Some people will be too eager to change. They will dive in, cut corners, over-simplify, and generally mess up the process.
- A development team may be in the middle of a project schedule. It may be best for them to complete the entire project using the current approach before considering anything agile.
- Some business areas may be difficult to convert to agile development. Consider highly-regulated industries, some government agencies, and any target customer that is slow-moving and overly deliberate. (Note: these are difficult but not impossible.)
For these reasons (and surely others), software development teams will transition to agile at different rates and perform at different levels. Some will excel, others will get by, and a few will struggle. You’ll never achieve uniformity. People are diverse and so are teams. Embrace it.
A few good teams will make the difference.
It helps to have a few individuals and a few teams who are agile development experts or role models. Focus on them. Help them achieve high-levels of excellence in advance of the rest of the company. Turn them into evangelists.
It’s a simple variation of the principle of leading by example. Get a few teams out ahead of everyone else. Help them be successful. Leverage their expertise and success. Once these teams build momentum, others will want to follow.
There’s no magic formula for selecting individual or team evangelists. Those selected need to be committed to making agile development successful and they have to be ready to change — continually. It also helps if they are outgoing and helpful by nature.
Resist the urge to get everyone lined up and moving on the same direction, especially at the outset. Once a few teams get started with agile development and demonstrate success, the others will naturally want to catch up. Before long, the slow start will turn into a stampede — and that’s a good problem to have.
My exploration of enterprise agile development continues with the topic of training and coaching — areas that are often overlooked or shorted.
When transitioning from a command-and-control development approach like waterfall to an agile approach like Scrum or Kanban, there’s a tendency to oversimplify. After all, the rules governing agile development, particularly Scrum or Kanban, are brief and simple. How tough can it be to follow them?
This oversimplification leads companies to go it alone. They dive into their chosen agile approach expecting to figure it out as they go. And so, the long, slow march to project failure begins.
There are many reasons why agile adoptions fail. One of the big ones is “sacred cows”. These are things, beliefs, people, processes, or anything else deemed to be above criticism. Sacred cows get special treatment and are protected. Agile teams have to work around the sacred cows.
Here are a few examples.
- A requirements document that must be formatted in a particular way and delivered at a particular time because some person or group “requires” it.
- An approval process involving phases and gates that must be followed, even by agile teams.
- A key contributor that refuses to play by agile rules but is untouchable and allowed to do things his way.
- A manager who defends her group’s independence and won’t allocate her people to the development team.
- An unsupported belief that customers won’t accept a shorter, product-release cycle.
These are difficult challenges that have to be tackled. People naturally fall back on what they know and how they’ve always done things. Even in the face of failure, there is a strong tendency keep doing what we’ve always done and to blame someone else for the problem — “It wasn’t my fault.”
Here’s what I recommend.
1. Get independent, professional assistance in the form of training and/or coaching. An independent agile expert won’t be influenced by your sacred cows. The expert will offer proven guidance based on personal and industry experience. You’ll be challenged to change or be forced to explicitly defend the status quo.
Send as many people to training as you can afford. There is strength in numbers. Get many people excited and motivated to try the new, agile approach.
2. Select a few staff members to become internal coaches/mentors (a.k.a. evangelists). This is the train-the-trainer approach. These people must be strongly motivated to change and equally motivated to help others. The formal training sessions will get everyone started and the evangelists will build upon the momentum.
Everyone will likely need continuing access to an independent, agile coach to answer questions, help resolve issues and overcome obstacles.
Challenge those sacred cows. Don’t accept anything as inevitable. Build a strong foundation for your chosen agile approach and start delivering software. As you build momentum, the sacred cows may actually want to climb aboard.
This post continues my exploration of what it takes to be successful with enterprise agile software development. The Scrum-of-Scrums only scratches the surface of what you’ll need to do. Let’s reconsider the role of the retrospective.
Everyone practicing any agile development approach should recognize that regular retrospectives are a critical success factor. Teams need to continually improve lest they fall into bad habits and stagnant routines.
There is an even bigger problem at the enterprise level. While each development team can conduct retrospectives and improve internally, the outward facing activities and team interactions may not benefit. Broad-based retrospectives covering multiple teams are needed to derive maximum benefits.
Consider this simple example.
A software application consists of three components, a graphics user interface, a service, and a device driver. For this simple example, let’s assume that we have three teams, one for each component. The teams may function well internally though no conclusions can be drawn regarding how they will work together.
Business people know nothing about system services or device drivers. They just want the application to work smoothly and reliably. They need the software parts to come together in a seamless and transparent fashion. If the GUI and the device driver are delivered on time and with good quality, but the service is delivered late or buggy, all three teams fail.
To get it right, the three teams have to work well together including a willingness to compromise. Whether a given software function belongs in the GUI, service or driver will, at times, be open to debate. The teams will need to figure it out on the fly.
It’s also likely that the three teams will operate somewhat differently. They may all be using Scrum, for example, but their definitions of done, their coding styles, and the rigorousness of their testing will likely be different.
Conflicts are inevitable. Joint retrospectives can help address them.
A good start is simply sharing information that comes out of the individual team retrospectives. There will be many ideas that span teams and can help everyone improve.
Next, conduct joint retrospectives among teams that work closely together and are heavily dependent on each other. These joint retrospectives will focus on team interactions and hand-offs. Again share the results so other teams may benefit.
Also consider broader retrospectives covering all the components of an enterprise application. It won’t be possible for all the members of every team to participate, but the teams can send representatives. Such broad retrospectives will focus on application-wide pain points likely to include software quality, output consistency, system performance, and team dynamics.
Retrospectives are great continuous improvement tools. Take full advantage of them and share the knowledge. For more information on retrospectives, take a look at my prior post on the topic called “Retrospectives Make Agile Teams Better”.
As I continue to explore what it takes to achieve enterprise-scale agility, I have to admit that I’m a big proponent of automation. I know many advocate physical Scrum or Kanban boards but they don’t scale. They can be used at the small team level but you have got to leverage software solutions to scale up to the enterprise level.
Automate your approach.
An enterprise with multiple, dependent, software projects has to roll-up team boards into higher level aggregated displays. Just as software components are integrated into services and applications, team boards have to be aggregated into status and flow displays that reflect what’s happening at the corporate level.
You could try to do this manually but I can’t recommend it. You’ll achieve better results and more transparency by having the Scrum or Kanban boards online, available for all to see (internally, of course).
I realize that daily stand-ups will need a way to gather around the board. An electronic whiteboard and a projector offer a simple solution that most enterprises already have in house. Give them a try.
Manual testing will never work.
Regression tests must be automated. Don’t even think about trying to roll-up an enterprise application and perform manual testing each time. It will never work.
Repetitive testing tasks have to be automated so they can run overnight. During the day, manual testing of new functionality can take place. Once the new functionality is stable, automate the testing (assuming that it will have to be repeated in subsequent builds).
Automated regression testing is a critical success factor. Don’t skimp on it.
We are social beings. Embrace it.
I strongly recommend using an internal social networking tool. No, I’m not suggesting that your teams use Twitter to report corporate information for all the world to see. Bad idea!
I’m recommending that you setup an internal messaging system using tools like Yammer or Salesforce.com’s Chatter. Such tools offer private messaging. Only authorized individuals will see information updates. You can decide how open (or closed) you want the communications to be.
Consider using a default condition of open to all with restrictions optional — as opposed to the reverse. In most companies, there is too much secrecy. It slows teams down, leads to poor decisions, and feeds redundancy. If you feel the need to lock down information, ask yourself why. What would be the harm in making the information available to all?
Using agile software development at the enterprise level presents many new challenges. I’ll continue to explore them in my next post.
In my article, “10 Tips for Succeeding with Enterprise Agile Development”, I referred to the need for a common vocabulary and standard rules for agile software development teams. You’d think these would be obvious and simple. They’re not.
A common problem in large development organizations lies in simple communication issues. Every software group establishes its own vocabulary and rules. When teams try to work together and share information, struggles quickly surface and the relationships get off on the wrong foot.
A common vocabulary helps.
For example, if software teams are using multiple development cycles over the course of projects, are those short cycles called increments, iterations, sprints or something else? Is the person making product feature decisions, the product owner, product manager, marketing manager, business analyst… You get the idea.
It’s fine for a group, working independently, to define a vocabulary for itself, particularly for internal concepts that are unique to the group and its deliverables. It’s not so fine when the group has to exchange information with other enterprise groups. People outside of software development don’t have the time to learn unique terminology for each software group they assist.
Sure, vocabulary differences are quite common — but so are misunderstandings. It’s really not that hard to get everyone on the same page with regard to commonly used terms. Don’t try to institutionalize every word people use. Identify the keywords that span organizations and migrate them to a common vocabulary. It will save you lots of headaches.
Here are a few areas where a common vocabulary can help:
- Project Management and Governance
- Software Test Results
- User Interface Elements
Standard rules also help.
For example, every software project, regardless of development approach, should have a “definition of done”. If someone on the team is asked to complete a task, how will the team know that the task is really finished? Teams need rules to guide them through such topics.
Many teams still use “percent complete” to indicate task status despite a large body of evidence showing how unreliable that metric can be. Always remember the adage that 80% of the work takes only 20% of the allotted time.
Teams can establish whatever internal rules they want but when software must be turned over to another group, there have to be rules that govern the hand-off. If my expectation of “done” is quite different from yours, we are headed for serious miscommunication when I deliver software to you.
Here are a few areas where standard rules can help:
- Project Estimates
- Definition of Done
- Documentation Requirements
- Test Types and Test Coverage
- Source Code Layout and Naming (If the source will be handed off)
- User Experience Design
Enterprise agile development is not the same as small team agile development — it’s more complex and challenging.
- June 2013 (8)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)