CC Pace’s Corporate Staff Meeting and Annual Party 2016

CC Pace President, Mike Gordon held a corporate staff meeting to review our previous year’s results and successes and introduce our business plans and initiatives for 2016.  This meeting provided a great opportunity for employees to understand CC Pace’s strategic imperatives and the direction on where CC Pace is headed this year.  In addition, the corporate staff meeting allowed all of our employees to gather together and have some valuable face to face time with one another. On a daily basis, a large number of our staff are working remotely or at client sites and it is a rare opportunity when we can all be in one place.

A highlight of the meeting was the celebration of Rechelle Card’s 10 year anniversary with CC Pace.  Rechelle, a Senior Technical Recruiter in our Staffing group, was recognized by Mike Gordon for the high value of service she has added to both the recruiting team and the company as a whole. Mike presented her with a service award and the traditional CC Pace gag gift – which was the development of her own TV show “The Recruiter”, a spinoff of “The Bachelor” – it was quite a humorous skit which included several staff members in the roles of candidates and a rose presented to the “winner”.  It was a “show” that is sure to be talked about for years to come!

Once the meeting concluded, we moved downstairs to Ruth’s Chris Steakhouse, here in Fairfax Corner, to enjoy our annual party. The food was excellent as always at Ruth’s Chris, from the beef tenderloin, crab cakes and shrimp to the delicious desserts!  There was something there for everyone to enjoy while reconnecting with fellow employees and getting to know some new ones! All our employees and their guests had a wonderful time and we all look forward to next year’s celebration!

According to James P. Womack and Daniel T. Jones, “Lean Thinking is a business methodology which aims to provide a new way to think about how to organize human activities to deliver more benefits to society and value to individuals while eliminating waste.” In my opinion, Continuous Delivery and DevOps are the application of Lean Thinking to a part of the software development lifecycle. In particularly, the processes that occur from the planning of software development to deployment of the software into production.

But how do you know if you need Continuous Delivery and DevOps? Well, here are some typical candidates for applying Lean Thinking in your organization via Continuous Delivery (CD) and DevOps.

Long cycle time or lead time
A couple of lean metrics are important measures of the amount of time it takes to deliver value to the end user. One of them starts from the moment the feature is identified (lead time). The clock starts on the other when development of a feature begins (cycle time). DevOps is more applicable to the cycle time. If your organization has long cycle times, then CD and DevOps are a great approach to reveal where those delays are and start to eliminate them.

If your development team is using Scrum, then long cycle times may already be very transparent. The development team should quickly be completing high value features regularly. But that doesn’t mean those features are getting deployed quickly.

Mistakes during deployment
When deployments do occur in your organization, are you experiencing technical issues? Ever have a roll back? These mistakes can be the result of many different causes. Generally, they come about because of the large number of manual processes during deployment. Problems occur because of communication issues between teams and a lack of familiarity with the steps necessary to deploy. Does each deployment seem new every time?

Another symptom is an organization where there is a “hero mentality” regarding deployment. What I mean by this is that there is an expectation that there will be lots of problems during deployment and some individual or small team will rescue the deployments by putting in lots of late hours, consuming multiple cans of soda, and eating pizza. This mentality is often even more entrenched when a particular individual becomes the “go to” person (the hero) for the deployments because only they know or can figure out how to do them. Sometimes the hero team or individual embraces this role, but often times they really don’t want the stress and constraints that it entails.

Large overhead in deployment process
Usually, as a direct result of the bad deployments mentioned above, organizations start to place much heavier governance on the deployment processes in an attempt to prevent mistakes. This can be manifested via complex change control processes. Usually, these are manual and include a change control board and heavy documentation (readiness reviews, traceability, etc.). As a result, deployments are slowed down even more. Sometimes so much overhead can cause a rush to get things done at the end by those that do the deployments which leads to more issues. Also, because more people are involved with the communication of what needs to be done, there is further chances of errors occurring.

User impact from deployment
Does your organization take systems offline during deployments? How long are those downtimes? And once systems are brought back online do they need to learn a large new feature set? Downtime can often have a negative impact on your mission to your users and drives a lot of organizations to deploy very infrequently. But the infrequency of deployment means that a lot of changes to the system are introduced during those deployments. Impact to users can be substantial and takes away from the value you are delivering to them.

Resistance from operations staff
Are your operations teams resistant to perform deployments? Would they rather see systems never change and just support the status quo? If so, then it is probably due to the complaints directed toward them because of the issues described above. Often they have little control to resolve those issues and feel blindsided by what they are getting from the development teams. I can assure you that it is a rare individual who enjoys the stress of a deployment gone wrong. Clearly DevOps can help with this.

Assessment
Of course, there are other measurements and policies that can be used to assess if you need to make changes to a non-DevOps environment or even improvements in your DevOps environment. Do you have more ideas or want to know more about assessing your need for DevOps, Continuous Delivery, or Continuous Deployment? Leave a comment below or contact us.

Recently, I attended a meetup for Loudoun’s Tech Startups in Ashburn, VA. It was a great opportunity to discuss ideas in various stages of development, as well as the resources available to bring these ideas to market. It was encouraging to see so many motivated entrepreneurs share their experiences in a local setting, with Loudoun showing its promise as a business incubator.

Michelle Chance from the Innovative Solutions Consortium gave a great speech about the services provided by her organization, such as “hard challenge” events, think-tank style meetings and student/recent graduate mentoring.

The hard challenge events seemed particularly interesting to me since they provide a collaborative environment for solving difficult technology problems. Organizations compete for the best solution and receive awards for most disruptive and innovative technologies.

Another sponsor of the event was the Mason Enterprise Center, which provides consultation and training to small business owners and entrepreneurs. They have regional offices in Fairfax, Fauquier, Loudoun and Prince William counties.

We attended this event because of our past experience developing collaborative solutions for startups. We’ve found that the Agile development philosophy fits nicely with the entrepreneurial spirit of organizations that want to quickly build a product that provides value. In fact, principles such as Minimum viable product and Continuous deployment are core to the Lean startup philosophy championed by Eric Ries. This method encourages startups to build a minimum amount of high-value features that can be released quickly. With frequent releases, a company can immediately begin collecting and responding to customer feedback.

If you’re at any stage in the startup process and have a technical idea that you want to explore or expand, there are plenty of resources available in the NoVa area. Also, I encourage you to attend one of the various meetups for startups, such as the Loudoun Tech Startups group.

We’ve all heard something about Documentation in Agile. I know I’ve heard some pretty extreme comments like “there is no documentation”. Well I’m here to set the record straight.

Let’s start by taking a look at the Agile Manifesto:

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

As you can see it isn’t that there is no documentation, but rather we favor the delivery of “working software over comprehensive documentation”. So what does that mean, and why did I emphasize the word comprehensive?

If you are fairly new to working on software projects, you may not remember the days of huge requirements documents like I do. Projects started out with a group of analysts working together to create a requirements package over the course of several months. We would engage with the customer, run workshops, and watch what users did. We’d end up with one or more three-ring-binders full of documents. There would be statements like “the system must….” and “the system should….” We would give each line item a priority (High, Medium, and Low typically). Then we would create as-is process flows, to-be process flows, context diagrams, data flow diagrams, object models, and state transition diagrams to name a few. Each set of requirements were presented to and signed-off by the main stakeholders; and that may have been the last our stakeholders heard from the team until the software was ready for user testing. At the end of the project, the documents would end up on a shelf somewhere eventually being shipped off to long term storage, never to be seen again.

The Manifesto reminds us that no matter how much documentation we create, if we don’t produce working software, then we aren’t creating value for our stakeholders. It also reminds us to evaluate the documentation we do decide to create in order to ensure it is of value for the project.

The perceived lack of documentation in Agile environments isn’t just because of the manifesto, it is because everything we do is slightly different in Agile compared to a waterfall approach. We no longer create a load of requirements and toss them over the wall hoping the team will understand them enough to create a design document and code. Instead, we work together throughout each sprint to ensure we are creating value together by delivering working software together where everyone has complete understanding of user stories, and everyone is on the same page regarding the design as it emerges sprint by sprint. When specific documentation like Release Notes, or User Guides are required a user story is an acceptable way to track these documentation needs.

As the team discusses user stories in grooming sessions, the goal is to have each story fully understood by the team. The team may suggest other stories, or identify other items they need. The Product Owner and Scrum Master can work together to obtain documentation that is needed by the team to better understand the story. The team adds notes to the story to track decisions and comments that are made  keeping story documentation with the story. So what else might the team need? When working with a user interface, the team will likely need a wireframe or mock-up of the user interface. The team may also want an object model or database diagram. I’ve even known one developer that requested a State Diagram. Unfortunately, there is no single correct answer. The team or Product Owner, may need to engage with other teams (System, Database, or DevOps) to get the desired documentation ready for the team. For a great article on best practices in Lean/Agile documentation check out this article http://www.agilemodeling.com/essays/agileDocumentationBestPractices.htm

The three main artifacts in Scrum are the Product Backlog, User Stories, and Test Results. The Product Owner holds the key to understanding stakeholder needs. Should other documentation be required from a stakeholder or compliance perspective, a story in the backlog is a great way to address this need. Also as development occurs, the team needs to ensure that system decisions and their code are sufficiently documented so those supporting ,or enhancing the system in the future will be able to do so adequately. Consider including something in the Definition of Done (DoD) to ensure stories meet these non-functional needs.

Yes, documentation does exist when following an Agile Framework. However, we don’t create a document for the sake of saying we’ve done it. Make a conscious decision of what will be created, and what the intended use is. This way, you won’t have a library of out of date, never to be viewed again documentation.

At CC Pace, we aren’t trying to fit you into a role; we’re committed to finding the best fit for you. Why? Because we are not your average staffing firm. This commitment is the reason our clients have stayed with us for over 35 years and why many of our candidates have worked with us for over a decade. As a recruiter at CC Pace, I strive to get the best sources available to keep up to our firm’s reputation.

‘Purple squirrel’ is a term used by recruiters to describe a job candidate with precisely the right education, specific, hard-to-find experience and qualifications that perfectly fits a job’s multifaceted requirements (Wikipedia). It may sound unrealistic, but if your hard work pays off, and maybe with a little luck, you find just the right candidate which fits your clients requirement – and that’s your purple squirrel.  You simply cannot afford lose them!

They’re in high demand. As the author of the article below says, you can’t just blast them with impersonal email and expect them to respond. They get dozens of those emails each week and it’s never going to work.  You can’t just tweet them a job title or send an InMail with a link to your job posting and expect them to drop everything and apply online. It just isn’t going to happen.

So, how is it going to happen?  There are some great tips in this article, Recruiting Purple Squirrels? Here’s the Trick, by Stacy Donovan Zapar, for courting your purple squirrel.  Enjoy and hopefully it adds to your recruiting arsenal.

At CC Pace, our Agile practitioners are sometimes asked whether Scrum is useful for activities other than software development. The answer is a definite yes.

Elizabeth (“Elle”) Gan is Director of Portfolio Management at a client of ours. She writes the blog My Scrummy Life. Recently, she wrote a fascinating post on how she used Scrum to plan her upcoming wedding.

How have you used Scrum outside its “natural” setting in software development?

Do you want to be more successful this year?  Do you want to improve your relationships, your health, and your life?  Well, the New Year is a common time for people to evaluate where they are in life, where they want to be, and to look at making a fresh start.  Once someone does this, they often turn to setting goals. Goal setting is an important process that starts with considering and deciding just want you want to achieve.

Who really sets goals?  Everyone from business professionals, students, parents, and athletes to entertainers and politicians.  People set goals for all types of things, the most common categories are:

• Artistic
• Attitude/Outlook
• Business/Career
• Education
• Family
• Financial
• Physical
• Public Service/Volunteerism

Experts advise that you:

• Write down your goal(s) to make the end result more real and obtainable.
• Once you have written down your goals, be sure to put the paper in a visible place (your bathroom mirror, the refrigerator, your desk, the dashboard of your car or even taped to your cellphone!) to remind yourself everyday of these goals.
• Come up with your action plan, listing the steps you need to take in order to achieve your goals.
• Stay focused and on track, and remember it is a process so take it day by day.

Once you start to see progress as you accomplish the steps you have outlined, this will help to keep you motivated and achieve your goal in no time!

Have you set goals for this year yet?  If not, it is time to get going.  This article, Golden Rules of Goal Setting, can help you get the process started.  Now is the time to reflect, take action and move forward – Good Luck!

Although our headline says Workshop VI, this is actually our seventh engagement with Art Chantker’s Potomac Forum on Agile in Government.  I love being part of these workshops on so many levels.  The historical Willard is so elegant and Art is a gracious host.  But the real value of the Potomac Forum Agile workshops is the in-depth expert knowledge provided by the trainers, guest speakers, panelist and interactive audiences in attendance.  For this latest workshop our instructors were David Patton, Government Practice Director, and Ashok Komaragiri, Senior Technical Consultant, both from CC Pace.  Our keynote speaker and panelists included senior officials from the Department of Homeland Security and the United States Patent and Trademark Office.  A very diverse audience included some people from industry and government representatives from NIH, National Science Foundation, Department of Agriculture, Library of Congress, Social Security Administration, FDIC, and other Federal agencies.

We kicked off our 2016 series with the topic DevOps – Taking Agility in Government to the Next Level.   Now that more and more agencies are starting to employ some Agile principles and seeing good results, the concept of better integrating the development teams with the operations teams is starting to garner more interest. David Patton took us through the basic precepts of DevOps, and painted a clear value proposition for considering this approach.  He helped the attendees to understand that both DevOps and Continuous Delivery are part of Lean Thinking, which has its roots in the manufacturing industry, and which has long been recognized as essential for process efficiency improvements.

Our keynote speaker posed the question that our government attendees were anxious to hear the answer to – Can DevOps Work Here?  His agency is proving that it can, with a combination of specific Lean-Agile practices combined with innovative procurement methods for facilitating the acquisition of the necessary resources to make it work “here” – in government.

An intriguing all-graphics presentation was the delivery approach of one of our other senior government officials.  In speaking about Lean-Agile architecture she highlighted the importance of keeping it simple, emergent, modular and loosely coupled.  This approach builds the framework for changes that we know will come.  She also emphasized the importance of using seasoned coaches for knowledge transfer as a key part of the successful implementation of these concepts.

After our working lunch David Patton facilitated our government panel of experts on how they are making DevOps work in their respective agencies.  He then continued with a presentation on the Lean concept for managing the flow of work and identifying bottlenecks and constraints in processes known as Kanban.  Finally, Ashok Komaragiri, Senior Technical Consultant for CC Pace, took us through a DevOps roadmap in his presentation A Guide to Your DevOps Journey.  He encouraged the attendees who want to begin adopting DevOps practices to break knowledge silos, integrate code continuously, and automate deployments as much as possible.

Reviews of the workshop coming in from government attendees have been outstanding.  One government official said that it was “One of the most informative training workshops I have attended”. If you haven’t attended on of these Agile in Government workshops, you should.

Senior IT managers starting a new project often have to answer the question: build or buy? Meaning, should we look for a packaged solution that does mostly what we need, or should we embark on a custom software development project?

Coders and application-level programmers also face a similar problem when building a software product. To get some part of the functionality completed, should we use that framework we read about, or should we roll our own code? If we write our own code, we know we can get everything we need and nothing we don’t – but it could take a lot of time that we may not have. So, how do we decide?

Your project may (and probably does) vary, but I typically base my decision by distinguishing between infrastructure and business logic.

I consider code to be infrastructure-related if it’s related to the technology required to implement the product. On the other hand, business logic is core to the business problem being solved. It is the reason the product is being built.

Think of it this way: a completely non-technical Product Owner wouldn’t care how you solve an infrastructure issue, but would deeply care about how you implement business logic. It’s the easiest way to distinguish between the two types of problems.

Examples of infrastructure issues: do I use a relational or non-relational database? How important are ACID transactions? Which database will I use? Which transactional framework will I use?

Examples of business logic problems: how do I handle an order file sent by an external vendor if there’s an XML syntax error? How important is it to find a partial match for a record if an exact match cannot be found? How do you define partial?

Note that a business logic question could be technical in nature (XML syntax error) but how you choose to solve it is critical to the Product Owner. And a seemingly infrastructure-related question might constitute business logic – for example, if you are a database company building a new product.

After this long preamble, finally my advice: Strongly favor using existing frameworks to solve infrastructure problems, but prefer rolling your own code for business logic problems.

My rationale is simple: you are (or should be) expert in solving the business logic problems, but probably not the infrastructure problems.

If you’re working on a system to match names against a data warehouse of records, your team knows or can figure out all the details of what that involves, because that’s what the system is fundamentally all about. Your Product Owner has a product idea that includes market differentiators and intellectual property, making it very unlikely that an existing matching framework will fulfill all requirements. (If an existing framework does meet all the requirements, why is the product being developed at all?)

Secondly, the worst thing you want to do as a developer is to use an existing business logic framework “to make things simple”, find that it doesn’t handle your Product Owner’s requirements, and then start pushing back on requirements because “our technology platform doesn’t allow X or Y”. For any software developer with professional pride: I’m sorry, but that’s just weak sauce. Again, the whole point of the project is to build a unique product. If you can’t deliver that to the Product Owner, you’re not holding up your end of the bargain.

On the other hand, you are very likely not experts on transactional frameworks, message buses, XML parsing technology, or elastic cloud clusters. Oracle, Microsoft, Amazon, etc., have large expert teams and have put their own intellectual property into their products, making it highly unlikely you’ll be able to build infrastructure that works as reliably and is as bug free.

Sometimes the choice is harder. You need to validate a custom file format. Should you use an existing framework to handle validations or roll your own code? It depends. It may not even be possible to tell when the need arises. You may need to use an existing framework and see how easy it is to extend and adapt. Later, if you find you’re spending more time extending and adapting than rolling your own optimized code, you can change the implementation of your validation subsystem. Such big changes are much easier if you’ve consistently followed Agile engineering practices such as Test Driven Design.

As always, apply a fundamental Agile principle to any such decision: how can I spend my programming time generating the most business value?

Face to Face is the best method of communication and that’s the method that Agile promotes.  The benefits of Co-located teams are numerous-  streamlines product development, promotes trust , accelerates communication among the team members, provides opportunities to collaborate, promotes reliability, fosters closer working relationship and the list of benefits can go on and on…..

Teams should co-locate as often as possible, because of the benefits of Osmotic communication.  Osmotic communication was coined by Alistair Cockburn, one of the originators of Agile.  “Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work”.

But in reality, not many of us have the luxury of working with our entire team in a single location. For most of the organizations I work with, the teams are all over the world. Many of these teams work with team members not only in different locations but sometimes in different continents.

So how do these Agile teams communicate and work with each other effectively?

Here are some simple ways to engage the entire team and not let any team members go in dark:

• Establish team core hours for facilitated discussions and working sessions. The team can establish a certain time of day when the entire team is available for group discussions: talk about the backlog, have design reviews or delayed discussions on any topic and dedicate that hour or two hours just for the team. The team members can be available on tools like Skype, or phone, and they can work on different things if the team doesn’t have any discussion items for the day. The idea is to have all team members available and ready to talk as if they are in the same room.

• Establish Team norms or working agreements. The team must decide on rules for working together and communicating with each other and these rules or working agreements should be followed by all team members and fair to all team members.  So for example, don’t have meetings that require one group in a certain time-zone to always be the ones to get up early or stay late.  Switch it around and make it fair.  Include things like phone etiquette in your norms.

• Utilize the Scrum of Scrum technique. A technique to scale Scrum up for large groups, consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. This same technique can be used when the team members are across continents and time zones and therefore cannot be available for Daily team ceremonies.  Each holds their own daily Scrum and then participates in a Scrum of Scums later on.

• Involve the entire team for Ceremonies. As much as possible, always involve all locations for ceremonies, such as Sprint planning, review, retrospectives, and daily stand-ups. Daily stand-ups or handoffs between remote teams bridge communications and establish a framework for frequent synchronization and collaboration.  If you have access to video conferencing, great!  If not cheap portable cameras attached to a chair and a laptop make a great improvisation.

• Rotate members around – cross pollinate. Rotate team members between various locations, this might be expensive but leads to a cross trained and fungible team. Even sending one person from each location to work with other groups will help build stronger working relationships and create cultural understanding.

• Use On-line collaboration tools. In the absence of co-location, teams will have to rely heavily on automated tools for collaboration and to create a single repository that keeps the efforts of the teams in full view for all team members.  The osmotic communication flow can be somewhat replicated for the distributed team using the virtual tools such as IM, Skype, Webex, and other on-line collaborative tools.

At  a team-level, use automated tools like Jira, Planbox, LeanKit, other shareware or low-cost options to maintain synchronization and visibility into work.  At the cross-team or program level, tools like Version One, Rally, other enterprise-level options can be used.

• Use a common document repository (ex. Sharepoint, Knowledgelink) for sharing information.
• Develop a shared team vocabulary and a team website
• Hold in person team meetings at regular cadence. Team members should meet others in person at regular intervals. While sometimes costly, this investment is worthwhile. People are the most important part of the team, they work really well together when they know and understand the person they work with just not a name. So setting up a regular cadence of team members meeting face to face helps improve the distributed team dynamics.
• Establish Clear Sprint goals and expectations. The team members should have clarity on the work they have to complete to meet the team’s objectives. Daily Scrums can be used by the team members to be mutually accountable and to set clear expectations for each other.
• Over communicate – When the team members are distributed sending in a quick summary of the discussions makes sure that everyone is on the same page.
• Be knowledgeable and respectful of the different cultures making up your distributed teams, such as holidays and working hours.

Lastly: Be patient.

If the team members are in different time zones being respectful and cognizant of the time difference is extremely helpful. Unless a decision needs to be made immediately, the team members should be given time to respond because they might be working on a different schedule or in a different time zone.

I’ve been working with large organizations where team members are in multiple locations quite a bit lately. This environment can be challenging, especially in ensuring everyone is engaged and not multitasking during Sprint Events. While there are a number of things I’ve covered in my blog “The Reality of Distributed Teams”, here are 4 specific things you can do to help build better agility with your remote teams.

1. Encourage team members in similar locations to meet in a room, and not just “dial-in” from their desk.

• Builds team continuity
• Reduces the urge to multi-task
• Follows the Agile Principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

2. Follow Sprint Event Agendas

• Ensures the team keeps on task and is not sidetracked
• Ensures we have a clear outcome to strive to for each event
• Keep to a time-box, and don’t create extra meetings to make up for not reaching the desired outcome at the end of a prescribed Sprint Event

3. Use a tool like planningpoker.com to size stories

• Simultaneous Pointing – reduce influence by more senior members
• Encourages discussion to get complete understanding of stories
• Supports “team sizing” instead of “individual” sizing

4. Allow for silence

• Creates an opportunity for the team to talk
• Product Owner and Scrum Master should not be doing all the talking, especially during planning. In Sprint Planning or Story Grooming/Refinement once the PO has introduced a new story, turn the meeting over to the team for questions and discussion amongst themselves. If there is awkward silence for a bit, it’s OK. Before moving on, be sure and ask if the team needs more time to discuss.

Whether your team has been together a long time or is just starting out, creating an environment for success by actively addressing remote issues is sure to add value to your team. Give these suggestions a try and let me know your successes!

Happy New Year! Did you make a New Year’s resolution?  Perhaps you’d like to spend more time with friends, lose weight, or maybe begin searching for a new career opportunity.  Many people use this time of year to make personal and professional changes in their life; studies indicate more than 40% of Americans make New Year’s resolutions.  Unfortunately, keeping those resolutions through the year is another story.  Research by the University of Scranton indicates there is only about an 8% success rate for achieving these goals (Forbes, 2013).  So how can you establish goals for 2016, and be successful?

Unfortunately, we can’t offer advice on weight loss or spending time with friends; you’re on your own for those resolutions!  But, when it comes to managing your professional career there are strategies for setting realistic goals and achieving them.  An article by Melody Wilding entitled, 3 Resolutions You’re Going to Break – and What You Should Resolve to Do Instead, talks about how to establish professional goals that create a successful outcome.

As we begin 2016, we encourage you to consider how you might incorporate these suggestions into your professional goals for the year. These tips just might help you achieve one of your 2016 New Year’s resolutions.

We’d welcome the opportunity to help you with your career this year, and encourage you to take a look at our current job opportunities.  Happy New Year!

As I sat watching Sunday Football, and thinking of my upcoming blog… I became aware of the similarities between football and Agile! Consider this, each time my football team has the ball, they have an end goal; to get points on the board. They also have intermediary goals, to deliver 1^st downs in order to retain the ball. They studied the opposition, and made some plans for the game. Then at the beginning of each play, they make a plan in the huddle, and execute. At half-time they have a retrospective.

So if you are into football, ask yourself; what would happen if they had to plan the entire game in advance? What would happen if they couldn’t respond to change within game or even the down? The ability of each player to take responsibility for their work, seeing the big picture, and responding to change as needed keeps the game going. It also parallels what we do when working in Scrum Teams.

Our big picture is provided by the Product Owner. Our end goal to deliver on the big picture incrementally by accomplishing 1^st downs. Sprint Planning allows us to see where we are and identify our plan for the sprint (football’s quarter). Our Daily Scrum allows us to plan the play for a day just like in a football huddle. Based on outcomes, we adapt to change continuing to focus on the end goal.

It takes the entire team to play the game. Each player must be accountable for what they are doing. Otherwise the quarterback gets sacked, the ball is fumbled, and overall play is stymied. There is total visibility. No one can hide if they don’t deliver. Sound familiar. It should. If it doesn’t, than your team may not be transparent about its work.

The Product Owner is like the Quarterback, supplying the team with user stories for the sprint. The Scrum Master is like the Coach, supplying support from the sidelines.

So when it comes to adapting to change vs following a plan, think about that football team you watch on Sunday night.  First, embrace the fact that being Agile allows us to adapt to change and that adaption is what helps us win the game. Second, make sure you make the most out of the huddle, or Daily Scrum, by truly planning how to move the ball, or story, down the field.  Finally, hold the team accountable while you drive to the end goal.  No football team ever wins on the basis of one player alone.

Recently, I had one of those rare moments when my son, a 3rd grader, seemed to understand at least part of what I do for work.

He was excited to tell me about the Code Studio site (studio.code.org) that they used during computer lab at school. The site introduces students to coding concepts in a fun and engaging way. Of course, it helps to sweeten the deal with games related to Star Wars, Minecraft and Frozen.

We chose Minecraft and started working through activities together. The left side of the screen is a game board that shows the field of play, which is your character in a field surrounded by trees and other objects. The right side allows you to drag and drop colorful coding structures and operations related to the game (e.g. place block, destroy block, move forward) in a specific order. When you’re satisfied that you’ve built the program to complete the objective, you press the “Run” button and watch your character move through your instructions.

Anyone familiar with automated testing tools can relate to the joyful anticipation of seeing if your creation does the thing that it’s supposed to do (ok, maybe joy is a strong word, but it’s kind of fun). In our case, we anxiously watched as Steve, our Minecraft Hero, moved through our steps, avoiding lava and creepers along the way. If we failed and ended up taking a lava bath, we tried again. If we succeeded, the site would move us to the next objective, but also inform us that it’s possible to do it in fewer steps/lines of code (never good enough, huh?!).

Together, we were able to break down a complex problem into several smaller steps, which is a fundamental skill when building software incrementally. We also had to detect patterns in our code and determine the best way to reuse them given a limited set of statements and constructs.  For my son, it was a fun combination of gaming and puzzle solving. For me, it was nice to return to the fundamentals of working through logic to solve a problem – no annoying XML configurations or git merges to deal with.

I’m a big supporter of the Hour of Code movement and similar initiatives that expose students to programming, but feel that there’s often an emphasis on funneling kids into STEM career paths. This is all well and good for those with the interest and aptitude, but coding also teaches you to patiently and steadfastly work through problems. This can be applied to many different careers. Chris Bosh, the NBA player, even wrote an article about his interest in coding.

I encourage students of all ages to check out the Code Studio site and Hour of Code events: https://hourofcode.com

This past year as CC Pace celebrates our 35^th anniversary, it has caused us many moments to pause and reflect on our good fortune.  Now, as we celebrate the holidays we have asked our employees to help us create a list of 35 Things they are thankful for this year.  Enjoy!

I am thankful for…

1. Good Health
2. The wonderful opportunity offered to me by CC Pace.
3. CC Pace’s flexibility and support that allows me the ability to fulfill my volunteer commitments.
4. Working within walking distance to Coastal Flats.
5. Clients who appreciate the high quality of our work and people.
6. Netflix
7. The new Star Wars movie “The Force Awakens”!
8. Our great company reputation built by previous and current employees.
9. Our Fairfax Corner office complex.
10. Phil’s laugh (Philippa Fewell is the Managing Director of our Enterprise Solutions practice)
11. CC Pace’s family friendly policies and atmosphere
12. The Thanksgiving Pie I received from Mike Gordon!
13. Fantasy Baseball Championship (or runner up!).
14. The Client to whom/which I was assigned –  I love this client, my team and my role on the team!
15. My children’s smiles that I see every day!
16. A great work Culture at CC Pace.
17. The Cloud.
18. The queso at Uncle Julio’s Rio Grande – yum!
19. My life, my love, my family (including our four footed creatures) and my work.
20. I am thankful for our great team here at CC Pace.
21. Family and good friends!
22. Online shopping
23. Staffing’s Holiday Breakfast!
24. Being able to spend the holidays with my family!
25. Today’s technology – after traveling for a week without access to a cell phone, I have a new appreciation for Google, text messaging and internet access!
26. Free parking at work!
27. Any day that 66 is not backed up!
28. Clay’s joke of the day – they never cease to put a smile on my face in the mornings.
29. My furbaby, despite the fact that when I rescued her, I did so under the belief that she was mute and calm. She is neither.
30. Amazon Prime for catering to my procrastination.
31. Hoverboards
32. Bagel and Donut day as well as the fresh fruit provided by CC Pace.
33. Being in a great location that minimizes my commute and affords many places to shop, eat and catch up on errands.
34. Moral victories in Fantasy Football.
35. The U. S. service men and women that protect our freedoms.

You are embarking on a new software development project. Presumably, if it’s a Scrum project, a team is assembled, space and workstations for the team room are configured and the first sprint is right around the corner. The time has come for the initial gathering of project team members and stakeholders – the Project Kickoff. The Project Kickoff meeting can range from an hour to several days, and provides the opportunity for the project team, and any associated stakeholders, to come together and officially begin (i.e., ‘kick off’) a project. The ultimate goal is for everyone to leave this meeting on the same page, with a clear understanding of the project’s structure and goals.

One of the more common kickoff meeting agenda items for Scrum teams today is establishing the product vision, or the product vision statement. Many definitions and examples of product vision statements are available with a simple internet search; a solid summary of the product vision can be found here in a 2009 member article written by Roman Pichler for the Scrum Alliance:

‘The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product.’

Here is where I have to come clean – I personally never thought much about the importance or impact of product vision statements until recently. It seemed to me that on many development projects, the product vision would simply exist as a feel-good placeholder or as a feeble attempt to energize the team: “We’re going to build this application and SAVE THE WORLD!”

I felt that the product vision statement was a guise for what seemed like the customary objective of a project which – in an admittedly negative opinion – was to provide a solid return on someone’s investment. Bluntly stated: “If we are successful, someone I’ve never met is going to make a lot of money on this product.” I observed that as a project ensued and the team became preoccupied with day to day tasks, reality would eventually kick in. At a certain point, the vision – which we were so excited about several weeks ago – usually becomes an afterthought.

Eventually, a point is reached several sprints into a project where the team’s project vision statement is scribbled on a large post-it sheet, taped to the wall in the team room, collecting dust – never to be spoken of again. In the past, my observation was that by the time our project wrapped up, we wouldn’t always take the time to measure project success against our original product vision statement. (In fact, many team members were probably already working towards achieving a new product vision on a completely new project.) We didn’t always ask the questions: Did we accomplish our mission? Did we meet all of our objectives? If not, why? (Some of these topics would assuredly be discussed in a Project Retrospective-type meeting, but in today’s reality, that isn’t always the case.)

Fortunately, times have changed. Several recent and personal discoveries (through complete happenstance) have improved my outlook; you could now say that I have a ‘newfound respect’ for the product vision statement. This inspiration is a result of successfully delivering on several development projects in the education research field. CC Pace has had the fortunate opportunity to partner with the National Student Clearinghouse (NSC) on several of their software development initiatives since 2010. Our first project supported NSC’s Research Center, whose mission is defined as ‘providing educators and policymakers with accurate longitudinal data on student outcomes to enable informed decision making.’

In June of 2010, CC Pace began the journey with NSC to redesign the StudentTracker for High Schools application (STHS 2.0), which contributes to NSC’s aforementioned mission as ‘a unique program designed to help high schools and districts more accurately gauge the college success of their graduates’. We began the project with an informative and efficient Kickoff meeting and established our product vision statement. Truth be told, I didn’t put much thought into it. After all, I was working with a new client on a newly-formed team, and Sprint #1 was approaching fast.

With all of that in mind, the following is a high-level summary (i.e., not verbatim and with some information added for clarification) of our product vision statement for the StudentTracker for High Schools 2.0 project from June, 2010:

NSC’s business goal is to leverage its unique assets and capabilities to provide the secondary-postsecondary longitudinal information required to inform the secondary education system in its efforts to increase rates of college readiness.

Redesigning the STHS 2.0 application will enhance the capacity and scalability to provide integrated secondary-postsecondary education information – in a timely and efficient fashion – to the maximum number of secondary customers possible.

The objectives to meet this business goal are as follows:

• Enhance STHS reports to include more insightful and actionable data resulting in more valuable and accurate information available to secondary schools and districts
• Provide for a more efficient file management process, reducing the turnaround time for data collection, processing and report distribution
• Increase data collection and storage capacity, allowing for more robust reports
• Improve NSC matching algorithms to enhance data quality and add reliability
• Design, configure and implement a robust set of longitudinal reports stratified by school type, demographics, gender, academics and degree

So, there it was. Our product vision statement was posted on the wall for all to see. As anyone starting out on a new software development project can attest, I still had some questions: Where is all of this leading us? Will we succeed? Will this application – which we are completely redesigning from scratch – launch successfully a year from now?

Undoubtedly these were realistic questions and concerns. At the same time, however, I began to realize that I was working as a member of a team on a development project with a realistic, measurable and highly-motivational product vision statement. I thought at the time that if we truly achieve our vision and successfully implement STHS 2.0 in the next year, our product will have a profound impact on educational research and potentially improve the college success rates of millions of high school and college students for years to come.

Fast-forward to 2015 – I can proudly say that I have seen several firsthand accounts demonstrating that we did indeed achieve the product vision that we established several years ago. The intriguing element of this discovery is that I never personally set out to measure whether or not we achieved our vision as a result of successfully delivering STHS 2.0. After all, this was over five years ago and I have worked on many different projects in that time. Instead, I discovered the answer to that question completely by chance, and on more than one occasion. Five years later, I came to the realization that our team’s product vision had indeed become a reality, and it was a really great feeling.

Check back for a follow-up post for the recent chain of events validating that our project’s product vision statement truly became a reality – more than five years after it was established.

As coaches, we help teams grow and mature.  Mature, effective teams understand each other – who they are, what they’re good at, what they’re not, what makes them laugh, what makes them cry, how they think, their intentions, their hopes, and their fears.

In my last blog, I talked about the Johari Window as a simple and intuitive model which can help increase self-awareness, and improve communication and interpersonal relationships.  It provides a way to visualize and understand how and in what ways we interact with ourselves and with others.

The Johari Window of a new team looks like Figure 1 on the left below, with a small Open area (public self) because team members haven’t had a chance to share much about themselves.

The Johari Window of a maturing team looks like Figure 2 on the right above, with an expanded Open area.

We can help a team go from a profile like the one on the left to a profile like the one on the right by providing opportunities and encouraging team members to engage in:

• Sharing information about themselves – expanding their Open area vertically and a reducing their Hidden area
• Giving feedback to each other – expanding their Open area horizontally and reducing their Blind area
• Discovering new information about themselves – expanding their Open area diagonally, and reducing their Unknown area

One place we can encourage that level of communication and interaction is in a team retrospective.

Introspective Retrospectives

I think of team retrospectives as 2 general types – those that focus on how we did our work, and those that focus on how we work together.

The first type centers on the process of doing work and how the team can improve their process.  The second type explicitly focuses on interactions and communications and how the team can improve the way they work together.  I call this second type an “introspective”.

As teams mature, these two types evolve into one, because the team will naturally begin to incorporate discussions about interactions and relationships as needed.  But for new teams, or teams with low trust, dedicated introspectives can often help them improve their interactions and team climate.

Opening the Window….with the Lens of Understanding

There are many tools, activities, and techniques that can be used to help a team expand their Open area.  A favorite of mine is to conduct an introspective using the “Lens of Understanding”.

As shown in Figure 3, the Lens of Understanding is a 4-quadrant model developed by Dr Rick Brinkman and Dr Rick Kirschner as a way to help understand behavior and what drives it.

In this model, the vertical axis indicates the focus of attention – is it on the TASK or on PEOPLE.  The horizontal axis indicates level of assertiveness – is it PASSIVE or AGGRESSIVE.

The premise behind this model is that people behave based on their intent.  By understanding the intents that drive behavior, we can better understand our own behavior and that of others.

In Figure 4, the Lens of Understanding describes four intents that shape behavior:

Get it done – if our focus is on getting something done, we tend to speed up vs slow down, act vs deliberate, and assert vs withdraw.

Get it right – if our focus is on getting it right, we tend to slow things down in order to see details.  We become absorbed in the task at hand and will likely deliberate before taking any sudden actions.

Get along – when we want everyone to get along, we tend to be less assertive as we put their needs above our own.

Get appreciated – when we want to get appreciation from people, we tend to be more assertive in order to be seen, heard, and recognized.

We all have the ability to change where we’re coming from (our intent) based on the context of any given situation.  And we each also have a “normal” zone, where we’re most comfortable and exhibit our best behavior.

As our intent changes, so does our behavior.  And when stressed, our normal zone behaviors can become exaggerated, as shown in Figure 5.

For example, let’s say in a particular situation, my intent is to “get it done”, and your intent is to “get it right”.  Our intents are at odds with each other, and if we don’t recognize that, or can’t find some middle ground, our stress increases.  In this example, my behavior would go toward Controlling, and yours toward Perfectionist.

Being aware of and understanding the intent behind behavior can help us understand and deal with different behaviors.

Using the Lens of Understanding

Below is a description of a retrospective designed around the “Lens of Understanding”.

Purpose:

• Provide a structured opportunity for team members to tell others about themselves, learn how others see them, and generate insights about themselves and others.

Objectives:

• Increase self-awareness of individual behavior
• Increase awareness about others’ behavior
• Expand Open area of each individual and the team as a whole

Supplies:

• Printed copies of the Lens of Understanding matrix (figure 3 above); two copies for each person
• Small stickies, pens, markers
• Masking tape
• Table set-up to accommodate work as individuals and pairs/quads, plus space to roam the room

Open the retrospective meeting

• Open with the check-in, temperature reading, and/or centering activity of your choice

Run the Activity

• Set-up
  • Hand out 2 copies of the matrix to each individual; ask them to put their name on each copy
  • Each person keep one copy on the table in front of them, and tape the other copy to their back (they’ll need to do this for each otherJ).
  • Facilitator draw the basic matrix (Figure 3) on the board and explain what the two axis’ represent
• Self-assess data
  • Do this part individually and without showing work to others
  • Each person put a mark on their copy of the matrix (the one in front of them) where they think they fall
  • For example, mark what quadrant they fall into based on whether they’re generally task oriented, or people oriented; and whether they’re generally passive, or aggressive)
  • If they have trouble, it might help to think about a specific work example
  • When they’re done, have them turn their copy over on the table in front of them
  • NOTE – this can also be done using stickies vs using a marker
• Feedback data
  • Everyone roam around the room and on the copy of the matrix on each person’s back, place a mark where they think that person is coming from (based on their observations and experiences with each individual)
  • This part may be lively, but ask them to do this without telling each individual where they’re putting their marks
  • Everyone take their seats when they’re done
• Introduce additional information about the Lens Of Understanding
  • Draw Figures 4 on the board; explain about the four general intents
  • Draw Figure 5 on the board; explain how stress can cause exaggerated behaviors
  • Each person take a few minutes to look at their two copies – how they see themselves vs how others have indicated they see them
• Discuss learnings in small pairs/quads
  • Form pairs or groups of four
  • Discuss insights and learnings with others in their pairs/quads
• Debrief at the group level
  • aha’s, surprises, shocks, puzzles
  • One thing they learned about themselves
  • One thing they learned about someone else
  • What will change for you on Monday?

Close the retrospective meeting

• Close with the closing/centering activity of your choice

Continuing the Journey

Developing self-awareness and mutual understanding within a team is an on-going journey.  Using the Johari Window model, along with thoughtful inclusion of activities like the Lens of Understanding, to help develop a team’s Open area will increase trust and create happier, more collaborative, productive, and successful teams.

Send me your comments…..I’d love to hear what you think and your questions, and your experiences, and ideas for helping teams grow.

In America there are an estimated 50 million pumpkin pies served on Thanksgiving Day each year!  After all, pie is the traditional dessert for Thanksgiving dinner, and that is something each employee at CC Pace knows very well.  Since the 1980s, CC Pace President, Mike Gordon has given each employee a pie for Thanksgiving to enjoy – and, not just any pie, but a pie from Mom’s Apple Pie Company.

Mom’s Apple Pie Company, based in Leesburg and Occoquan, Virginia is owned by Avis Renshaw and has been featured in Southern Living Magazine, Fox News, Chowhound.com and many other news outlets bringing the spotlight to their famous pies. Mike Gordon came upon Mom’s Apple Pie Company, many years ago when both businesses were located in the same complex. Since then, Mike has made it a tradition to provide a pie for each employee during the holiday season.

Over the years, it is estimated that CC Pace has purchased over 1,000 pies from Mom’s for our employees.  While pumpkin pie is the most popular pie across the nation, at our offices the Top 5 Pie Selections are:

1. Wild Blueberry Crumb
2. Pecan
3. Butter Pecan Apple Crumb
4. Chocolate Meringue
5. Bourbon Walnut

So it appears, the taste buds at CC Pace are quite a bit sweeter than what a pumpkin pie delivers. Although, maybe the question we should be asking is, why aren’t CC Pace employees ordering this Thanksgiving staple? How many employees are choosing to bake their own pumpkin pies? Those are some questions we will need to explore for next year’s Thanksgiving blog!

On November 5, 2015, Phil Fewell, Managing Director at CC Pace, and I attended ACT-IAC’s Emerging Technologies Community of Interest sponsored workshop held at GSA Headquarters on the topic, Overcoming the Challenges of Acquiring Agile Digital Services in Government.  I moderated the panel of experts on the subject which included Traci Walker from US Digital Service, one of the original architects of the TechFAR and the Digital Services Playbook; Eric Cho from DHS’ Procurement Innovation Lab; Navin Vembar, the IT Director for the Integrated Award Environment (IAE) who we work with at GSA; and Dave Zvenyach with 18F, a GSA entity that provides digital services, including some Agile development to other Federal agencies.

The discussion centered on how the acquisition process and the contractual language of the Request for Proposal (RFP) can be structured in order to better facilitate acquiring Agile digital services, while still adhering to the Federal Acquisition Regulation known as the FAR.  Attendees heard what others are doing in the government to support their agency’s adoption of Agile methodologies and frameworks.

Traci Walker, who has 15 years of experience as a Federal Contract Officer, emphasized that the TechFAR document, of which she was a key contributing author, should make it clear to all agencies that the FAR in no way prohibits the adoption of Agile development practices in government.  In fact it encourages such innovation.  Eric Cho outlined some of the experimental approaches that the Department of Homeland Security (DHS) has been implementing to acquire Agile services in their component agencies.  David Zvenyach from 18F shared some of their recent awards to industry and how 18F interfaces with government agencies interested in their services.  Navin Vembar discussed the advancements at GSA in using Agile development on their large IAE program.

The response to this topic was so strong that we had to turn some people away.  So ACT-IAC will be doing two more of these sessions, one on December 10^th and another on January 21^st.  We are suggesting that the December and January sessions both limit industry attendance to no more than 50% of the total in order to allow for more government participation.  I expect to moderate the January panel and hope to see you there.

It is said that the President of the United States is the most sought-after interview subject in the world. However, there’s another president just outside of the DC border (in Fairfax, Virginia to be exact) who may feel like a close second, as he’s had quite the interview agenda recently. Earlier this month, the #1 business radio show in the country, Executive Leaders Radio, sat down with CC Pace’s President, Mike Gordon, for an exclusive interview. We recently did the same, and while we may have asked different questions, both interviews unveiled unique and surprising facts about Mike and what it takes to be president… of CC Pace.

So, who is Mike Gordon, really? We asked Mike for 10 minutes where we threw random and fun questions his way to help us gain some insight on our leader. Always a good sport, here are his responses:

How old were you when you got your first real paying job? What was the job?  I was about 10 years old, and I took over a friend’s paper route delivering the Wilmington Morning News. 

Who is CC Pace and how often do people ask you that?  Occasionally someone asks me who CC Pace is, but more often the question I get (at least a couple of times a month) is where did the name CC Pace come from.  There is no person named CC Pace. I am happy to share the evolutionary story of how the name CC Pace came to being with anyone who has the time.

Describe your first sale/customer?  The first customer that I supported coming out of college was the Department of Energy (DOE), which was our largest client at the time.  The country had recently gone through an energy crisis with gasoline shortages and the DOE wanted to be better equipped to handle a similar situation, should it occur in the future.  I built a very small system that allowed the federal government to capture gasoline inventories that would be reported by the states in the event that rationing was needed. To the best of my knowledge, the system was never actually used.

Describe the first customer you lost and why?  Ironically, I would say that the first customer that I lost was Freddie Mac.  I had been part of a CC Pace team that had worked on building MIDAS, Freddie Mac’s legacy system.  Over time, I was the only CC Pace person remaining on the project and I communicated to Freddie Mac that this was a sustainable model for us.  When nothing changed, a former director from Freddie Mac who had joined Fannie Mae asked me to bring a team over there to help redevelop Fannie’s systems which is what we did (Like MacArthur, I returned 4 years later).

Who was the first employee you ever hired?  I’m not sure.  Philippa Fewell (the current Managing Director of our Enterprise Solutions group) is the first person who I remember interviewing, but I was not the ultimate decision maker. Jane (Abdunnur) Dwight is the first person who I remember hiring to a management position, but I suspect that there may have been others who I hired before that.

How many hours of sleep do you get on average each night?  7 (I like to get 8 hours when I can), but invariably there are some nights I only get 5 hours or less.

What is the last book you read?  The Snowball:  Warren Buffett and the Business of Life

What is the last movie you saw in the theater?  American Sniper

How would you describe yourself in one word? Practical

Golf or Tennis?  If golf, what’s your best score?  Tennis in my youth, golf now.  Best golf score on a legitimate course is 78.

What is your favorite restaurant?  Villagio in Clifton, Virginia

What is the best piece of advice you ever got from one of your children?  Don’t sing in public!

Have you ever met anyone famous?  I have met a number of famous people, with the most impressive being Maya Angelou.  She was a long-time supporter of SOME (So Others Might Eat) and I met her at a private reception during one of their annual galas.  When she spoke, her words were so full of imagery, her messages were always so powerful, and her voice was more commanding than anyone else who I have ever heard in my life.

What is your favorite band?  Bruce Springsteen and the E Street Band

Thanks Mike, now we know the boss likes The Boss, can hold his own on the golf course, and has had a great work ethic since the young age of 10!

Want to learn more about Mike Gordon?  You can check out Mike’s segment on Executive Leaders Radio and hear how at the age of 16, he and his brother took over his family’s business – not realizing how much impact that one decision would have on shaping him into the leader he is today. Executive Leaders Radio is the #1 business weekly radio show in the country and is broadcast nationally to an audience of 7 million listeners.

Like Martin Fowler, I am a long-time Doctor Who fan.  Although I haven’t actually gotten around to watching the new series yet, I’ve been going back through as much of the classic series as Netflix has available.  Starting way back from An Unearthly Child several years ago, I’ve worked my way up through the late Tom Baker period.  The quality of the special effects is often uppermost in descriptions of the classic series, but that doesn’t actually bother me that much.  Truth be told, I feel that a lot of modern special effects have their issues, too.  Sometimes modern effects are good and sometimes they’re bad; the bad effects are bad differently than those in the classic series, but at least the classic series didn’t substitute effects, good or bad, for story quality or acting ability.  To be fair, the classic series also has its share of less than successful stories, but the quality on the whole has remained high enough that I keep going with it.  (In my youth, I stopped watching shortly after Colin Baker became The Doctor, although I can’t remember if I became disenchanted with it or if my local PBS station stopped carrying it.  I’m very curious to see what happens when I get past Peter Davison this time.)

I’ve also been very interested to see the special features that come with most of the discs.  As a rule, I don’t bother with special features as I find them either inane or annoying (particularly directors talking over their movies), but the features on the Doctor Who discs have mostly been worth my time.  Each disc generally has at least one extra that has some combination of the directors, producers, writers, designers and actors talking pretty frankly about what worked and didn’t work with the serial.  I’ve learned a lot about making a television show at the BBC from these and also about the constraints, both technological and budgetary, that the affected the quality of the effects on the show.  (Curiously, it also brought home the effects of inflation to me.  I’d heard the stories of people going around with wheelbarrows full of cash in the Weimar Republic, but that didn’t have nearly as much impact on me as hearing someone talking about setting the budget for each show at the beginning of a season in the early 1970s and being able to get only half as much as they expected by the time they were working on the last series of the season.  Perhaps because I do create annual budgets, the scale is easier to relate to than the descriptions of hyperinflation.)

While I am sure there are those are fascinated by what I choose to get from Netflix (you know who you are 😊), I actually had a point to make here.  I recently watched the Tom Baker episode The Creature from the Pit, which has a decent storyline but was arguably let down by the design of the creature itself.  (There are those that argue it was just a bad story to start with and those that argue that it was written as an anti-capitalist satire that the director didn’t understand.)  As I watched the special feature in which Mat Irvine, the person in charge of the visual effects including the creature, and some of his crew talked about the problems involved in the serial, I realized that this was a lovely example of why we should value customer collaboration over contract negotiation.  Apparently the script described the creature as “a giant, feathered (or perhaps scaled) slug of no particular shape, but of a fairly repulsive grayish-purplish colour…unimaginably huge.  Anything from a quarter of a mile to a mile in length.”  (Quote from here.)  I suspect someone trying to realize this would have a horrible time of it even in today’s world of CGI effects, but apparently in the BBC at the time you just got your requirement and implemented it as best you could even though both the director and the designer were concerned about its feasibility and could point to a previous failure to create a massive creature in The Power of Kroll.

Alas, neither the designer nor the director felt empowered enough to work with the writer or script editor (or someone, I’m unclear on who could actually authorize a change) on the practical difficulties of creating a creature with such a vague description, resulting in what we tend to have a laugh at now.  I don’t know what the result would have been if there had been more collaboration in the realization of this creature, but it seems to me that the size and shape of the creature were not really essential to the story.  Various characters say that it eats people, although the creature vehemently denies this, and we see some evidence that it accidentally crushes people, but neither of these ideas requires a minimum size of a quarter of a mile.  It seems like the design could have gone a different way, that was easier to realize, if everyone involved had really been able to collaborate on the deliverable rather than having each group doing the best that it could in a vacuum.

Many times I have seen newly formed or new to Agile teams and organizations moving from Scrum and/or Kanban to eventually settling for Scrumban as they mature. As I reflect on these teams that I have worked with, I feel that their ultimate form of Scrumban is probably their own kind of Shu-Ha-Ri progression.

Shu Ha Ri is a Japanese martial art concept, and describes the stages of learning to mastery.

Shu – the student copies the teacher’s moves as perfectly as possible. The teacher corrects the student if the movement is imperfect, inefficient, or ineffectively performed.

Ha – In this stage, the student understands the principles well enough to depart from rigid practices. The student experiments and makes observations of the new techniques. The newly emerged techniques become his own.

Ri – stage, the student has reached a point of mastery and is able to teach and to adapt to new situations easily.

Shu – the journey begins
Teams and organizations new to Agile and in infant stages of Agile transformation start off as being Scrum .They start following all the Scrum practices, conforming to the roles of the Scrum and they kind of follow the prescriptive form of Agile, or Scrum which makes sense. Installing a basic set of proven Agile practices by force can start yielding quick benefits for the organizations, letting them see how the new methodology leads to working faster and delivering the value out to the customer quicker. It kind of builds confidence at the team level too. The teams and the organization are both at the Shu level.

The team keeps having the daily scrums, planning sessions, locking the sprint, reviews and retrospectives in a prescribed manner till it becomes muscle memory.

When a team produces consistent results using rigid methods, they have completed their Shu stage.

As an Organization, these successful practices are also replicated to other areas to see the benefits in the other parts of organization.

Ha – adjusting the sails
With each retrospective and in the spirit of constant improvement, they change the practices to what make sense for their own unique solution. Teams start to feel maybe Scrum isn’t the right way for what they are doing.

Some teams don’t want to be restricted by the lock down of sprint commitment and want to be able to pull their work. Some of the teams want to move away from the planning session or role demarcation but still like the way certain things worked in Scrum and start to work on what is the “Ha’ phase. In the Ha stage, teams often will start to innovate their processes and the way they design their software. They may adopt new methods and tools in dealing with each other. Retrospectives are the key in the Ha stage to gauge the effect of the newly formed processes: are they helping the team or taking them back into the post Scrum era.

The Ha stage will include some successes and some failures, but it will be a learning experiment and the team will be wiser and mature with each of these experiments.

As an Organization starts doing Scrum in various teams and divisions, it becomes clear that one size doesn’t work for all aspects of the software development, and some prescriptive processes which work for majority of teams clearly need more refinement or customization to work for the other teams. This is the organization getting into the ‘HA’ phase. This can be extremely useful for existing Scrum teams looking to improve their scale or capability.

What the discovery leads to is Scrumban, an Agile management methodology that is hybrid of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.

Scrumban is a pull-based system, where the team no longer plans out the work that is committed to during the planning, instead continuously grooming the backlog. The same Scrum meetings (planning, review, and retrospective) can still take place, but the cadence of them can be more context-driven. The main emphasis is on limiting the work in progress (WIP).

With Scrumban, a team benefits from the prescriptive nature of Scrum while the process improvement of Kanban allows their process capability to continuously improve (kaizen) , reducing the waste and simplifying the way they work. In all of this they develop something new and unique to the team and hence get to the “Ri’ stage.

Ri – losing sight of the shore
At the Ri stage of an Agile transition, the team becomes capable of abandoning rules and strict forms while increasing the productivity and customer experience. They can produce quality work, with the rule or methodology of their own.

As an Organization, it might be a new flavor of Methodology which works best for the company itself.

We have an immediate opening for an Avaya-Certified Telecommunications Engineer who will provide telecommunications engineering support for a federal organization in Washington DC with several thousand end users and 10+ locations, and owns and operates a distributed PBX system that supports (7) locations in Virginia, Maryland, and Washington DC. The candidate will possess Avaya Certified Specialist (or higher) Certification and technical knowledge of high specialized telecommunications applications/operational environments, high-level functional systems, and design integration of exceptionally complex systems.This position is on-site in downtown Washington DC. The primary shift is M-F, 10:00 AM – 6:30 PM, with earlier hours during the training period.

Responsibilities
The job responsibilities include but are not limited to:

• Assisting agency technical experts with current telecommunications projects such as: planning; implementing; testing; training; documenting requirements; task change documentation; maintaining the voice switch hardware, software, switch; network and equipment requirements; and daily telecommunication operations.
• Other support responsibilities include voice telecommunications systems such as PBXs, call centers, and peripheral systems/applications, wireless systems, messaging and automated attendants, paging (overhead, internal, commercial), call accounting, uninterruptible power supplies (UPS), audio conferencing, mobile devices, cellular, smartphones, tablets, and other similar telecommunications devices.
• The successful candidate should demonstrate technical knowledge of current and emerging telecommunications services and systems.

The successful candidate will have experience with:

• Routing diversity; Redundant service; Local and long-distance services; Primary rate interface (PRI); Direct inward dial (DID); Tie lines (T-1); DS-3; internet services; analog facilities; physical infrastructure
• Voice/Data networking; Audix Voice Messaging; Avaya Aura Messaging (6.x)+; Communications Manager 5.2, 6.3+; Aura Conferencing 8.x; VOIP Solutions; SIP; Station/Switch administration; World class routing; Location Base routing; Enterprise Survivable Servers
• Tracking, updating, and documenting work in a ticketing system such as FootPrints, Remedy, Clarify, etc.
• Demonstrating proven analytical and problem solving skills
• Updating schematics and drawings using Microsoft VISIO or comparable tool
• Ability to manage multiple projects, work under pressure and tight deadlines, work independently, and work in a team environment
• Follow all ticketing standards for timeliness, accuracy, documentation, routing, etc.

Qualifications
Avaya Certified Specialist or higher certification

10 years of experience in the following functional areas:

• Knowledge of systems architecture and tools to update Visio drawings and schematics
• Telecommunications Industry Certification
• Inventory database maintenance and updates as inventory changes
• Preparing and performing management briefings
• Developing internal documentation, such as SOPs, instructions or user guides
• Conducting question and answer sessions with user groups;o Developing and executing test plans in accordance with agency standard operating procedures
• Technical knowledge of highly specialized telecommunications applications/operational environments, high-level functional systems, and design integration of exceptionally complex systems
• Excellent proven written and verbal communication skills

Must Have:

• Avaya Certification
• 10 years of Telecommunications experience
• Excellent customer service skills
• Excellent written and verbal communication skills
• Experience with ticket management (Remedy, Clarify, FootPrints, etc.)

Before I get to how much capacity there is in a sprint, let’s take a look at the flow. If you are doing Scrum, you are probably familiar with a diagram that looks something like this:

When it comes to figuring out what day to start on, and when each ceremony should be done, I thought it would be nice to see it all laid out and explained in a calendar format. Here is my calendar view (there are others) of the ceremonies for 2-week sprints.

No matter what numerical day of the month it is, I recommend starting sprints on Wednesday or Thursday. The reason is simple: it is easier to get everyone to attend Sprint Planning, Sprint Review and Sprint Retrospectives when they don’t fall on Monday and Friday’s. If you are experiencing difficulty in attendance to these ceremonies when they are on Monday’s and Friday’s, consider moving the first day of the sprint to Wednesday or Thursday. With continuous delivery, you can promote code to production on Thursday, rather than on Friday. Thursday promotions to production allow first day support to happen on Friday, rather than the weekend!

Day 1 – Sprint Planning – The Product Owner has the stories prioritized for the upcoming sprint all ready and presents them to the team. The team will size (if not already sized), discuss the design and tasks for the stories, and commit to what they can get done. Allow adequate time for the team to work together to complete tasking and commit to the work.

Day 6 – Grooming – While the Product Owner is always refining stories and getting them ready for the team, they must also meet with the team on a regular basis to get their input into upcoming stories. During the grooming meeting the team can let the Product Owner know what additional information might be needed to consider the story ready for a sprint. If there is enough information for the team to size stories, this is a great time to do so.

Day 9 – All Code in QA Environment – I know this isn’t a ceremony, but it is worth pointing out. Stories should be between ½ day – 2 days of work, this means that stories are flowing into QA throughout the sprint. By Day 9, if you have a lot of code still in process, how will it be tested in time for the Sprint Review on Day 10? Developers can be busy doing fixes, code documentation, refactoring, or helping test each other’s code to ensure everything is ready for the demo portion of the Sprint Review.

 Day 10 – Review & Retrospective – Typically 1 hour for each ceremony. Remember that the Retrospective is reserved for team members only.

Day 2 – 10 Daily Scrum – Keep this ceremony short and sweet allowing just 15 minutes for the team to check in with each other. Answering the 3 questions, is to help them plan. It isn’t a status meeting.

For more on the ceremonies, go right to the source here http://www.scrumguides.org/

Calculating Sprint Capacity
I use this calendar to show the flow, plan for the meetings, and to identify my teams’ capacity for the sprint. How many hours does your team actually get to code in a sprint?

Typical Day – Considered to be 6 hours at most organizations based on an 8 hour day with 2 hours of email, admin and other meetings.

Days in a Sprint – 10 (if there aren’t any bank holidays or vacations) = 60 hrs per person, per sprint

Sprint Ceremony Allocation – Planning (4), Scrums (9 x .25), Review (1), Retrospective (1), Grooming (1) = 9.25 hrs per person, per sprint

Average Capacity per person = 50.75 hours (60 – 9.25 hrs)

This can be adjusted to suit your ceremony timings, and for holidays and vacations. (Hint: For a 3 day weekend reduce capacity by just 5.75 hours as everything else has already been deducted.)

Why is capacity important?
A team’s commitment may not be to last sprints velocity, if their capacity is reduced. It is good to understand the impact of holidays and vacations on velocity as a result of reduced capacity. Is this a surprise? Let me know. I’m always interested in your comments and feedback. Happy Planning!

CC Pace hosted a celebration for our 35^th Anniversary on October 15^th at our headquarters in Fairfax Corner.  The event was a cocktail reception where employees, clients, friends and CC Pace Alumni enjoyed cocktails and delicious hors d’oeuvres while reminiscing and reuniting.

The highlight of the evening was a special presentation by President, Mike Gordon who explained how the company began, and the intriguing story behind the name CC Pace! During his presentation, Mike took guests on a whirlwind tour of all the locations CC Pace had called home before moving into our current offices in 2002.

CC Pace choose to commemorate our 35th Anniversary by giving back to our local community by hosting a food drive for a local food bank with a goal to donate 350 lbs. of food. Through the generosity of all our employees and guests, we collected 451 lbs. of food for the Lorton Community Action Center!

Seeing so many clients, friends and familiar faces in our offices that evening, we were honored to have been able to share such a grand achievement with so many who have played a part in our success!

As most of you who operate in the Federal space are probably aware at this point, many Federal agencies are now utilizing Agile methods such as Scrum to manage their software development efforts. The goal for most of them is to reduce risk and accelerate system delivery to their end users. By using Scrum with the development team they have achieved part of their goal. But major risks and speedbumps still exist after the software is developed. These are encountered during deployment by the operations groups and are normally outside the purview of the development team.

The de facto approach to this issue in the private sector is Continuous Delivery and DevOps. That same approach is now being successfully applied to the public sector. Just how well is the government doing in its attempts to adopt this private sector best practice?  On November 18^th Dr. David Patton, Federal Practice Director, and Ashok Komaragiri, Senior Technical Consultant, both with CC Pace, will be joined by Joshua Seckel and Jaya Kathuria from the Department of Homeland Security, Tina M. Donbeck from the U.S. Patent & Trademark Office and John D. Murphy, with the National Geospatial-Intelligence Agency, to take an in-depth look at the state of DevOps in the Federal government.

For additional information visit: http://www.potomacforum.org/content/agile-development-government-training-workshop-vi-devops-%E2%80%93-taking-agility-government-new

In my last post, I talked about the interesting Agile 2015 sessions on team building that I’d attended. This time we’ll take a look at some sessions on DevOps and Craftsmanship.

On the DevOps’ side, Seth Vargo’s The 10 Myths of DevOps, was by far the most interesting and useful presentation that I attended. Vargo’s contention is that the DevOps concept has been over-hyped (like so many other things) and people are soon going to be becoming disenchanted with the DevOps concept (the graphic below shows where Vargo believes DevOps stands on the Gartner Hype Cycle right now). I might quibble about whether we’ve passed the cusp of inflated expectations yet or not, but this seems just about right to me. It’s only recently that I’ve heard a lot of chatter about DevOps and seen more and more offerings and that’s probably a good indication that people are trying to take advantage of those inflated expectations. Vargo also says that many organizations either mistake the DevOps concept for just plain operations or use the title to try to hire SysAdmins under the more trendy title of DevOps. Vargo didn’t talk to it, but I’d also guess that a lot of individuals are claiming to be experienced in DevOps when they were SysAdmins who didn’t try to collaborate with other groups in their organizations.

The other really interesting myth in Vargo’s presentation was the idea that DevOps is just between engineers and operators. Although that’s certainly one place to start, Vargo’s contention is that DevOps should be “unilaterally applied across the organization.” This was characteristic of everything in Vargo’s presentation: just good common sense and collaboration.

Abigail Bangser was also focused on common sense and collaboration in Team Practices Applied to How We Deploy, Not Just What, but from a narrower perspective. Her pain point seems to have been that technical stories that weren’t well defined and were treated differently than business stories. Her prescription was to extend the Three Amigos practice to technical stories and generally treat techincal stories like any other story. This was all fine, but I found myself wondering why that kind of collaboration wasn’t happening anyway. It seems like doing one’s best to understand a story and deliver the best value regardless of whether the story is a business or a technical one. Alas, Bangser didn’t go into how they’d gotten to that state to start with.

On the craftsmanship side, Brian Randell’s Science of Technical Debt helped us come to a reasonably concise definition of technical debt and used Martin Fowler’s Technical Debt Quadrant distinguish between different types of technical debt: prudent vs. reckless, and deliberate vs. inadvertent. He also spent a fair amount of time demonstrating SonarQube and explaining how it had been integrated into the .NET ecosystem. SonarQube seemed fairly similar to NDepend, which I’ve used for some years now, with one really useful addition: both NDepend and SonarQube evaluate your codebase compared to various configurable design criteria, but SonarQube also provides an estimated time to fix all the issues that it found with your codebase. Although it feels a little gimmicky, I think it would be more useful than just having the number of instances of failed rules in explaining to Product Owners the costs that they are incurring.

I also attended two divergent presentations on improving our quality as developers. Carlos Sirias presented Growing a Craftsman through Innovation & Apprenticeship. Obviously, Sirias advocates for an apprenticeship model, a la blacksmiths and cobblers, to help improve developer quality. The way I remember the presentation, Sirias’ company, Pernix, essentially hired people specifically as apprentices and assigned them to their “lab” projects, which are done at low-cost for startups and small entrepreneurs. The apprenticeship aspect came from their senior people devoting 20% of their time to the lab projects. I’m now somewhat perplexed, though, because the Pernix website says that “Pernix apprentices learn from others; they don’t work on projects” and the online PDF of the presentation doesn’t have any text in it, so I can’t double check my notes. Perhaps the website is just saying that the apprentices don’t work as consultants on the full-price projects, and I do remember Sirias saying that he didn’t feel good about charging clients for the apprentices. On the other hand, I can’t imagine that the “lab” projects, which are free for NGOs and can be financed by micro-equity or actual money, don’t get cross-subsidised by the normal projects. I feel like just making sure that junior people are always pairing and get a fair chance to pair with people they can learn from, which isn’t always “senior” people, is a better apprenticeship model than the one that Sirias presented.

The final craftsmanship presentation I attended, Steve Ropa’s Agile Craftsmanship and Technical Excellence, How to Get There was both the most exciting and the most challenging presentation for me. Ropa recommends “micro-certifications,” which he likens to Boy Scout merit badges, to help people improve their technical abilities. It’s challenging to me for two reasons. First, I’m just not a great believe in credentialism because I don’t find they really tell me anything when I’m trying to evaluate a person’s skills. What Ropa said about using internally controlled micro-certifications to show actual competence in various skill areas make a lot of sense, though, since you know exactly what it takes to get one. That brings me to the second challenge: the combination of defining a decent set of micro-certifications, including what it takes to get each certification, and a fair way of administering such a system. For the most part, the first part of this concern just takes work. There are some obvious areas to start with: TDD, refactoring, continuous integration, C#/Java/Python skills, etc., that can be evaluated fairly objectively. After that, there are some softer areas that would be more difficult to figure out certifications for, though. How, for example, do you grade skills in keeping a code base continually releasable? It seems like an all-or-nothing kind of thing. And how does one objectively certify a person’s ability to take baby steps or pair program?

Administering such a program also presents me with a real challenge: even given a full set of objective criteria for each micro-certification, I worry that the certifications could become diluted through cronyism or that the people doing the evaluations wouldn’t be truly competent to do so. Perhaps this is just me being overly pessimistic, but any organization has some amount of favoritism and I suspect that the sort of organizations that would benefit most from micro-certifications are the ones where that kind of behavior has already done the most damage. On the other hand, I’ve never been a boy scout and these concerns may just reflect my lack of experience with such things. For all that, the concept of micro-certifications seems like one worth pursuing and I’ll be giving more thought on how to successfully implement such a system over the coming months.

As Agile Coaches, we help teams grow and mature. But there’s no how-to manual that tells us how to do that.  So how do we accomplish it?

Today I’ll talk about a model I find useful when working with teams. The “Johari Window” model was developed by Joseph Luft and Harry Ingham in the 1950’s from their work with groups.  “Johari” comes from a mash-up of “Joe” and “Harry.

What is it?
The Johari Window is a simple model, a tool that can help build trust and improve interpersonal relationships within a group by increasing self-awareness and mutual understanding, and improving communications.

Johari’s Window has 4 quadrants:

OPEN
The public self or open persona.

This quadrant represents what you know about yourself that others also know about you (includes behavior, knowledge, skills, attitudes, strengths, weaknesses, etc).  This is the self we share with others.

BLIND
The blind self or naïve persona.

The blind area represents what is known by others, but you are unaware or don’t know about.  We can’t access the positive things in this area because we don’t know about them, and negative aspects that we don’t know about make us vulnerable.

HIDDEN
The private self or secret persona.

This quadrant presents what you know about yourself, but keep hidden from others.  These are the things that make us uncomfortable or that we’re not confident in.

UNKNOWN
The undiscovered self or mysterious persona.

The unknown area represents what is unknown by you and unknown by others.  This dark area is where our deepest fears and buried talents reside.

The model is based on two fundamental concepts:

• Trust and growth can result from being open
• Awareness and self-development can result from asking for feedback

 How is it used?
Johari’s Window can be used from an individual, team, work group, or project perspective.  The ultimate goal is to increase the “open” quadrant….expanding the public self, and reducing the hidden, blind, and unknown areas.

Opening this window is accomplished by:

• Telling others about yourself…..willingly sharing your thoughts and intentions. The more people know about us – how we think, what’s important to us, how we make decisions – the more cooperatively, collaboratively, and effectively we work together.  The sharing here refers to things that are appropriate for the environment, e.g., sharing intimate details isn’t appropriate at work, and would not have a positive effect on relationships in this setting.
• Asking others for honest feedback….on how they experience you and what impact your behavior etc has on them. Be open to receiving feedback, as it’s a way for us to learn what others see but we don’t, highlighting opportunities for growth.

It’s important to acknowledge here that the word feedback has a negative connotation in American culture.  That’s because feedback is usually couched as “friendly advice” about what we’re doing wrong, or delivered in a context of judgement and intimidation, e.g., “you’re wrong/broken, and you need to fix this or else”.  So we fear it.

But feedback is really about the person giving it, not about the person receiving it.  Most of us have good intentions; we do what we think is right, for the right reasons, and are unaware that others might receive it differently than we intended.  Feedback isn’t about us being wrong or broken, but rather a way for others to tell us our impact on them.  It is a gift….ours to do with what we want.

• Introspecting regularly….regularly looking inside, honestly assessing what we want, how we behave, what we have to offer, what we need to develop, and increasing our self-awareness.
• Challenging ourselves….take more risks, expand boundaries, solve bigger problems, work with different people, or execute on a bigger stage. This will tap into and reveal our deepest fears and help us discover unknown strengths.

So what do I do next?
Whether you’re using the Johari Window model for as an individual or for a team, the key is the more developed the “open” area is, the more comfortable, happy, successful, and collaborative we’re likely to be.

Stay tuned for my next installment where I’ll talk about crafting a team retrospective using concepts around the Johari Window.

Send me your comments…..I’d love to hear your questions, experiences, and ideas for helping teams grow.

Resilience.  It is defined as: the capacity to recover quickly from difficulties; toughness.  It is something that many of us were taught early as toddlers by our parents. We’d fall down, and they would say, “Get up, shake it off, keep on going”. In school, maybe you ran for class office and didn’t win, or you tried out for a team and didn’t make it, or you applied for a certain college and didn’t get accepted.  And again, your parents would say, “It is okay, you tried. There is something else out there for you, keep trying, move forward; there is a better fit for you somewhere else”.  And as you get older, the stakes become bigger, you want that perfect job with the perfect company, you want that promotion and perhaps you are not successful 100% of the time.  Resilience.  According to the author, Jeffry Harrison, of the attached article, resilience is the one quality all successful people have in common.  People aren’t born destined for success; it is not fate. They have something in common: they are resilient.  He says that we are all born with this in us, we just have to learn to develop it and use it.  Interesting, right?  Develop it and use it.  So when those speed bumps feel like mountains, get up out of bed, pull the blinds back and take steps to move forward….

Enjoy the below article by Jeffry Harrison, and the three lessons he has learned to use and improve your own resilience in your professional life.

https://www.themuse.com

We conclude our three-part 35^th Anniversary blog series about our past, present and future by talking with Mike Gordon, President of CC Pace, on his vision for the future of CC Pace. Mike has built and led a company that has grown by attracting people with a common set of beliefs that focus on quality, integrity and keeping customers’ best interests in mind while delivering results.  As our leader, learn how he plans to drive the company forward.

What are you most excited about when you think of CC Pace’s future?
A new set of leaders who will set their own vision and their own path to get there.  We have a lot of very talented people here who, combined with some people we will bring in from the outside, will become our new leaders. It is these new leaders who will bring new ideas and approaches to help us provide innovative solutions to be delivered to our clients in the future.

What one goal for CC Pace tops your list when you think about the next 3-5 years?
One goal that stands out when I think about the future is leadership development and transition.  We are focused on grooming and mentoring our leadership from the inside, receiving outside leadership training, and the opportunity to try (and sometimes fail) as we pursue new business opportunities and models for execution.  We are in a people-based business and we need to be spending sufficient time developing our current and future leaders,   while still delivering on our current day-to-day business and the needs of our clients.

In what areas do you see CC Pace growing in the next 5 years?
From a revenue standpoint, the federal market will likely see the most growth.  We have made a committed investment there that we are just now starting to reap the rewards.  On average, the projects for the federal space tend to be larger and longer-term than private sector projects.  That being said, I also anticipate growth in all of our practice areas. The Financial Services industry is starting to turn around and rebound, and new opportunities are developing there. For Staffing, I see us continuing to stay in the high end of the value-oriented staffing arena versus commodity-based staffing, and I see increased demand for this type of service. Our Agile practice, which includes training, coaching and software development, will expand as a result of our marketing strategies and as we introduce new offerings to the market.

From a corporate perspective, it’s in marketing.  Finding new, quality clients is fundamental to sustaining and growing any vibrant business.  We’ve long lacked a dedicated strategy and commitment to marketing and let repeat/referral business drive revenues.  Today, under our Corporate Marketing Manager, Jenna Bayer’s leadership, we’ve made tremendous strides to change that, and I expect that this marketing initiative will continue to grow and develop.

How does CC Pace’s current focus prepare us for the future?
Two things that prepare CC Pace for our future is the type of people we hire, and our business model.  The people we hire are adaptable, creative and solutions-oriented. They are good at solving problems and are very customer-focused, which is key for a B2B business. Our people have strong values; you can teach people a lot of things, but values is often not one of them. These values are important because individual values need to be in alignment with our company values.

The market is constantly changing and our business model is designed to be very adaptable. We are able to look at what is going on in the market and determine what solutions will work for each unique situation. Part of this adaptability is the diversification of our three business units (Enterprise Solutions, Financial Services and IT Staffing) which complement each other.  CC Pace’s business model focuses on delivering value to our clients and it is this outcome-driven business model that sets us up for long-term relationships with our clients.

When you think about the future of CC Pace, what is the biggest challenge you see for the company?
The biggest challenge I foresee is dealing with change. Change is good, but it can be a challenge. While we deal with change management frequently with initiatives at our clients, it’s often difficult to apply those lessons ourselves.  In order to be successful in the future and move to a new leadership team with new vision ideas, we will need to change and grow as a company and as individuals.

How will CC Pace continue to be successful in the Agile space in response to Agile methodologies that are constantly evolving?
The methods will continue to advance and change. We want to be on the forefront both for when we are using the methods to deliver solutions, and when we are training and coaching others to do so.  We’re seeing a change right now with Kanban, DevOps, Scaling methods, advanced Agile engineering methods and tools.  Ideally, we have a good balance of training/coaching vis-à-vis development – we are able to have our trainer practitioners vacillate between exploring new ways and gaining new experience, and then being able to share that knowledge with others.

What is the one bit of advice you’d like to bestow upon the next generation of CC Pace?
My advice would be this: be clear about your goals and be patient to get there.  Make sure that you have people who are aligned with what you are trying to achieve.  Most importantly, recognize that it is less about the speed by which you get there and more about staying focused to arrive at your desired target.

The future of CC Pace is in the hands of our leadership team; a team that Mike Gordon has successfully led and mentored for three-and-a-half decades.  As CC Pace continues to grow and evolve in the years to come, we will remain a committed partner, whose goal is creating value-added results and solutions for our clients. Stay tuned for the next 35 years!

Development of your business strategy requires a long and hard look ahead to the future. Anticipating what the industry may look like, what your customer profile may be and what technology might be available is critical.  Yet as important as looking forward is, it is equally critical for an organization to look back and analyze how you got here, what has made your company great and how you’ve managed to retain and build your customer base over the years.  The combination of these views will play a significant role in designing a powerful ‘move forward’ strategy for your organization.

In recent years the financial services industry has been heads down focused on navigating the regulatory environment, including the most widely recognized and intrusive regulation of TRID. As a result, any vision for long-term strategic planning has taken a back seat. As TRID begins its final march toward implementation, it’s high time for the industry to begin looking beyond the recent strains of compliance and begin to recall the lessons learned from the past and imagine what the future might be with the development of an effective business strategy.  Adidas learned this lesson by regaining control of their future after taking a long, hard look at their past to ensure they break the chains of recent history.  Read more about it in Strategy+Business, who wrote “How Adidas Found Its Second Wind”. It’s now time for the financial services industry to get its “Second Wind”.

Welcome to the final part of my 12 Principles series where we’ll cover the final 4 Agile Principles. (In case you missed it, here’s a link to Part 1 and Part 2). If you utilize all three parts together, you will have a great resource for working with your teams’ Agile growth.

9. Continuous attention to technical excellence and good design enhances agility.  
We may be working in short sprints, but this is not an excuse to let technical excellence slip. Potentially deliverable means the code is tested and passes.

Technical debt is dealt with on a regular basis, and not left until the very end of the project.

This isn’t one and done, so support your teams to be the best they can be. Allocate approximately 20% of each sprint to “technical excellence” https://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx. Some basic things you should be doing are planning for Test Driven Development (TDD), pairing and refactoring. Developers create simple designs, and look for constant improvement through regular feedback.

One final thought, Technical Excellence is about more than developer’s code. It is also about the organization becoming more Agile. Think about working with all members of the organization to improve their skills by cross pollinating, training, and mentoring.

10. Simplicity–the art of maximizing the amount of work not done–is essential.
 The phrase to remember is not to “gold-plate” your features. One best practice here is to follow TDD. By developing to the story and its acceptance criteria until the test passes, and no more.

Some developers may feel they could do more, but what if what they create won’t be used? Then we have wasted time, and a potentially untested item. It’s great to have ideas, so write a story and pass it to the Product Owner for prioritization in the backlog. Remember it’s easier to create complicated solutions, harder to create simple solutions… but simple solutions last longer, increasing quality and decreasing total cost of ownership.

11. The best architectures, requirements, and designs emerge from self-organizing teams.
Change can be difficult, and moving from a waterfall environment to an Agile environment is no exception. In order for team members to identify the best design during Sprint Planning, they must be knowledgeable about the environment and system they are creating. This means we can’t treat them like mushrooms (keeping them in the dark, and feeding them “fertilizer”).

If your organization is working with complex systems, ensure the architectural runway is in place. Expect some ramp-up time for team members to become familiar with the environment. Ensure that there are resources assigned from the “systems” team to support each scrum team. Create domain models, physical models, etc. as needed to ensure sufficient information is available to the team. Then allow sufficient time for the team to discuss and build on their designs during Sprint Planning.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Welcome to the Retrospective! Agile is an empirical process. Based on the results, we adapt and improve. When I hear that teams are struggling with retrospectives, I suggest they rethink how they think about this ceremony. It isn’t a gripe session. It is an honest introspection of our performance.

Following this principle means we need to take a look at how we are doing, and commit to experiment to create small improvements. Each and every sprint allows us to try something out, and to look at the results at the end. If the results are positive, great. We can decide to run with the change. If the result isn’t positive, we can choose a different approach for the next sprint. There are great resources out there to keep Retrospectives from becoming dull and boring. If you are struggling, take a look at the book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen.

It is easy for an organization to be “Scrum-but”. The risk in staying “Scrum-but” is not truly getting all the benefits of being Agile. Read all three parts of this blog and evaluate how your organization is doing. I invite you to add your comments and experiences, as we share in the Agile Community any ideas for continuous improvement!

 “How much scrum would a Scrum Master master,
If a Scrum Master could master scrum?
He would master, he would, as much as he could,
And master as much as a Scrum Master would.
If a Scrum Master could master scrum.”   —-Cindy Bloomer

When recently meeting with a client a very interesting question came up: How many teams should a Scrum Master Scrum? They had been hearing that a Scrum Master’s role is just a facilitator role and all the Scrum Master has to do is run the ceremonies, so a person in the role should be able to run 2-3 teams without any issue. Therefore a novice Scrum Master should just be Scrumming one team, an experienced Scrum Master can safely handle up to 2-3 teams and a very experienced Scrum Master can handle more than 3 teams.

In my opinion, the experience of the Scrum Master does not translate well into the number of teams they can handle. Although it is a factor, in all honesty, there are a number of factors that influence the decision, such as organizational maturity, team maturity, project type, the value of the project, and the effectiveness of the Scrum Master role.

Is the Scrum Master just a facilitator? If so, then yes, the Scrum Master can be over 2-3 teams.
Because then the expectations are just to run the ceremonies and make sure teams are running well, are working towards the objectives set in PIs, and are meeting the sprint objectives. And even for this scenario, the team needs to be a mature team. A team that has been together for at least 6-8 months has worked through the forming, norming, storming, and are now in the performing phase and no one on the team is very role specified. They believe that they have to accomplish stuff as a team.

It also depends on the Organization’s Agile Maturity. If the organization has just started the Agile Transformation journey and has yet to establish Scrum Practices, then the Scrum Master should just be dedicated to one team.  This is because they will have many impediments to resolve, and they will need to help team members understand and see the value in Agile practices. Helping a newly formed team adopt Agile practices will be a full-time job for the Scrum Master.

With all that said, I believe there are many factors that help determine the “best” number of teams for a Scrum Master to handle; the experience of the Scrum Master is just one of these factors. I have seen many experienced Scrum masters running just one team and declining to work on multiple teams at a time. Although I agree in some organizations Scrum Masters don’t have a choice – the number of teams a Scrum Master handles is a key differentiator in performance, both team performance and Scrum Master Performance.

I want to hear about your thoughts and experiences with the effectiveness and the Scrum Master role when it comes to scrumming multiple teams…

Today, join us for an inside look at CC Pace present day as we continue our three part blog series about our past, present and future in celebration of our 35^th Anniversary. When it comes to learning more about CC Pace’s culture and what makes us unique, we’re not just talking about free coffee and whether or not you can wear jeans to work on Fridays (which you can). We gathered three employees from different business units within the company to give us their perspective of CC Pace.

Meet Seth Greenwood, Technical Recruiter in our Staffing division.  Seth is a 2012 graduate of James Madison University and has been with CC Pace for 2 years.

How did you first hear about CC Pace?
I applied online through a job posting on Monster.com.  Rechelle Card, Senior Technical Recruiter at CC Pace, then contacted me regarding the position. When we spoke, she piqued my interest in CC Pace by telling me about the clients they support and the opportunities for placements.  The company I was working for at the time had a much smaller client base, so CC Pace sounded very attractive to me. I was seeking a greater exposure to both commercial and government clients and CC Pace clearly fit that model.

What at CC Pace motivates you about your job?
I truly enjoy helping people find their next place of employment.  I also appreciate that CC Pace’s mission is different than many other staffing companies in the Washington DC area.  We are very quality-centric here with an emphasis on finding the right person for the job; it’s not just a numbers game.

Do you feel CC Pace offers a good work-life balance?
Yes, in the sense that, while you’re expected to perform, you do not have extremely aggressive quotas and rapid turnover that is common in other staffing companies.  I can go home at the end of the day and enjoy my personal time relatively stress-free. We also have flexibility with our personal schedules.

Seth, for these next three questions just tell us the first things that comes to your mind:

Describe CC Pace’s President Mike Gordon in three words?
Leader, affable, approachable

What are your three favorite things about CC Pace’s location?

1. Being located in Fairfax Corner, we have a number of dining choices
2. Plenty of parking
3. Close proximity to Fair Oaks Mall

Describe CC Pace’s culture in three words?
Collaborative, Fun, Casual

Meet Cindy Bloomer, Managing Consultant and Agile Coach for our Enterprise Solutions practice.  Cindy has been with CC Pace for 7 years. Based out of her home office in Salisbury, North Carolina, she spends the majority of her time at client sites as an instructor for in-house Agile Training and Coaching engagements.

What do you love best about the culture here? Why?
The work environment is very fun, supportive and engaging. We have many entertaining social events, activities, and company meetings throughout the year. These occasions give the employees a chance to reconnect since many of us may be on projects at client sites for extended periods of time. CC Pace also offers employees great support when dealing with personal issues or medical problems, and allows you to take the time you need to deal with the situation – and that says a lot!

How do you feel you have a voice in the direction of your future at CC Pace?
We work hard and have opportunities for growth via engagements that are challenging and rewarding.  We often have a say in which assignments we get, and who we work with on a project.  Everyone is assigned a “development manager” to help develop our skills, and I routinely interact with mine. CC Pace is very open and transparent internally.  Personally, I participate in business planning and strategy for my business unit.  I get to see and hear about our corporate state and business plans at our all hands company meetings.

While working at CC Pace, what is your favorite memory so far?
We had a party at the office where we played a series of games. Some games we broke into teams and some were played individually, even our leader Mike Gordon played along.  There was one game in particular that was hysterical, I cannot recall all the details, but I do remember it involved Oreos!  That was a great event where everyone companywide was able to interact with one another.

Cindy, for these next three questions just tell us the first thing that comes to your mind:

What are three words that Sum up your overall experience thus far at CC Pace?
Satisfying, Engaging, Supportive

What are three things you have learned while working at CC Pace?

1. Recently, I took Scaled Agile Framework (SAFe) courses and was able to get my SPC (SAFe Program Consultant) Certification. I’ve also been learning more about Kanban.
2. By gaining experience as an instructor, I’ve learned many techniques and increased my comfort level speaking in front of a group. Now, public speaking is at a point where it’s just second nature.
3. Working with colleagues at CC Pace has opened my eyes to various tactics for solving problems and approaching tasks. By observing and working with colleagues, I’m constantly being exposed to new ways to accomplish the same things using a different approach.

Name three characteristics of CC Pace you credit to the company’s success?
Relationship oriented, Family-like culture, Adaptable

Meet Keith Kemph, Senior Consultant in our Financial Services division.  Keith has been with CC Pace for 3 years. He is a seasoned management consultant who collaborates with our clients on numerous types of projects that include Business Transformation, Process Improvement, Reorganization, Vendor Selection Strategy, Program Management and much more.

How do you rate CC Pace’s expertise in your industry?
Unparalleled. Bottom line, our financial services consultants are actually mortgage banking experts. The average consultant has been in the mortgage banking industry for twenty three years. As mortgage banking experts we are unmatched in our ability to efficiently design, build, implement and execute on projects. We measure success by successfully completing projects, driving results and ROI. As evidenced by 80% of our projects coming from prior clients, for the last 35 years.

Working remotely, what steps do you and your CC Pace team take to stay connected?
Great question for someone who lives in Denver, Colorado works on-site at our clients’ office (currently Columbus, Ohio) and whose corporate office is in Fairfax, Virginia. Bottom line, it’s tricky. I have to rely on three key things; weekly team calls, daily emails and several visits to corporate each year. I only wish it was as easy as it sounds on the surface (lol).

How do you feel that the work you are doing is aligned with your professional goals and interests? Frankly, I feel like the luckiest guy on earth! While most people ‘fall’ into consulting, I have always known I wanted to be a consultant. I’ve always had a desire to help solve a company’s biggest and most complex challenges in order to help increase efficiencies, reduce costs and improve their bottom line.  Pace’s boutique approach ensures that we remain client and quality focused while rich with knowledge and experience that I continue to learn from. All of which is in direct alignment with my professional goals.

Keith, for these next three questions just tell us the first three things that comes to your mind:

Tell us three things that attracted you to CC Pace?
Simply said: Experience, Reliability and Integrity.

What three things would you want a prospective client to know about CC Pace?

1. We are all about solving our client’s greatest challenges, project, or issue, efficiently and effectively.
2. We are truly our client’s partner. It’s easy to say you’re a partner, but to truly be an effective business partner it requires listening intently to our client needs, asking the right questions, collaborating with them to design and implement effective solutions.
3. The most important aspect of or culture, is the relationship. Regardless if you’re a colleague or a client we place significant value on having a relationship with everyone we engage. Through these relationships we build a level of trust that allows us to truly accomplish astonishing results.

Describe CC Pace in three words?
Focused, fun and friendly.

Over the course of this three-part blog series, I will cover all of the 12 Principles. In this second installment I hope I’ve peeked your curiosity. As I said in Part-1, I believe following these principles is the core of being “Agile”.  Is your organization embracing the fundamental principles of Agile? Are you open to culture change?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 

OK, we’ve hired good people, who want to do a good job. Now we just have to show them we believe in them. If it were only that easy. Too many times fear drives an organization. Too many project failures, a culture of distrust, or simply a mindset of “this is how we’ve always done it” leads to micromanaging and difficulty in enabling teams to take ownership of their work.

I’ve personally been a part of many organizations who falter when trying to motivate teams. Or, even worse they totally fail in the trust arena. Is it scary to start moving away from micromanaging and micro-reporting? I’m sure it is. With Agile we have built in controls to help us manage teams at “arms-length”. We can listen in on Daily Scrums, and must attend the Sprint Review to see the teams’ sprint accomplishments and provide feedback. Yes, a team may “fail”, but what have you lost? In a two week sprint, you may have lost a little time. Do you think the team will have learned from the Sprint? Will they try harder to succeed next time? Is a two week loss better than a year of micro-managing and still not getting the desired results? You bet!

Organizations need to ensure the teams are supported appropriately with dedicated team members, regular involvement by the business, access to information, and ownership of delivery. Motivate the team with small rewards and acknowledgement of successes, and watch them deliver!

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation 

Most of us recognize that when we are together face-to-face communication flows. Spontaneous questions are raised, and connections are made.

This principle may not be so easy to follow if the teams are not collocated. Put a little extra effort into the use of technology to emulate face-to-face communication whenever possible. Team members will form stronger bonds. The benefits include stronger and more motivated teams, as well as reducing risk of miscommunication including errors regarding the intent of user stories and acceptance criteria.

Lead by example, and allow introverts to have their privacy, but don’t miss this opportunity to build team that becomes highly performing.

 7. Working software is the primary measure of progress 

I was once told “watch the runner, not the baton”. Too many times, organizations focus on hours worked (or sat in the office), rather than actual outputs. This principle reminds us that what we really want to watch is the outcome.

Agile measures velocity of the teams’ completed work. If a team is struggling to meet their commitment, then look at root causes. It is likely there are other issues that need to be addressed. Are the user stories actually “ready” to be accepted into the sprint? Is someone trying to get the team to commit to more work than they can deliver? Start with small steps and build on successes. It is a success when the team delivers what they commit to. Then ask the team to identify process or people improvements during their retrospective to help grow velocity.

Place your emphasis on seeing quality deliverables at Sprint Reviews, not on how long the team works, or how busy they look.

 8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

We’ve all had those moments where we feel staying just a little bit late at work, or skipping lunch will help us meet our deliverables. After all, it’s just “this time”… if only that were true! Instead, working late and skipping lunches becomes a habit. Next thing you know, it isn’t just one team member; it’s the majority of the team. While some leaders jump for joy, there are repercussions.

Even outside of software development workers engaged for more than 50 hours a week open themselves up for health issues, and may not actually be as productive as they would working a standard week. See http://www.cnbc.com/2015/01/26/working-more-than-50-hours-makes-you-less-productive.html

 When it comes to software, the idea of working at a sustainable pace originates in XP practices. Over time implementation of all the principles enable us to create an environment where all teams can work at a sustainable pace. See http://www.langrsoft.com/articles/sustainablePace.shtml

 Work-life Balance isn’t just a cliché. Put working at a sustainable pace into practice, and watch the results.

With just one more installment left, I look forward to your comments. Let me know how your organization incorporates the Agile Principles into their culture, or struggles you face in following Agile Principles.

You’re driving along on a four-lane freeway.  For a football field’s length in front of you, there are no cars.  And behind you, a similar distance is free of traffic.  It’s like you’re all alone – I know, I know, for some of you that seems an impossibility, but go with me here.

It’s about 10 o’clock on a bright, sunny Monday morning and you’re headed up the east coast for a business meeting a few hours away.  There are big fluffy clouds in the sky, you’ve got the sun roof open, your music is blaring, and you’re singing along – not well, but nobody can hear or see you, so who cares?

The speed limit is 70 mph, and you’re in the third lane from the right going between 72 and 74, making sure not to go over that magic 5 mph “speed-safe” window.  You’re alert to the situation around you, not rushing to overtake the cars in front of you, yet staying ahead of those behind you.  You’re relaxed, and content with the progress you’re making.  You check the rearview mirror, and suddenly.…

BOOM!

There’s a car in the lane behind you.  Barreling down on you.  Going 15, 20, maybe even 25 miles faster than you are.

What’s your first reaction?

DANGER!! Don’t Move!
My first reaction is….danger, stay alert, don’t move.

I watch what the car’s doing.  It’s approaching so fast, there’s no way for either of us to safely recover if we both make a move in the same direction.

So I maintain my speed, stay my course, and watch to see what happens.

The car comes right up behind me, so close I can’t see the head lights in my rearview mirror.  And sits right on my tail.

O.K., buddy
Really?

With all this space to go around me, you’re going to sit right on my tail!?!

And what’s with the wiggling back and forth, is that a signal for me to do something?  Maybe a sign that you’re a madman?

What do you expect me to do, move over?

Why should I?  After all, you had, and still have, plenty of room to safely get around me.  It’s not like I’m going slow, it’s just not fast enough for you.  Well, I’m not gonna move over.

But maybe I’ll slow down juuust-a-bit.

A Common Response
My reaction above is considered “passive-aggressive”.  A passive aggressive response is a way of indirectly retaliating or resisting demands made by others.  It’s a subtle way of expressing irritation, anger, or resentment, when we can’t communicate directly with others or don’t know how to express those feelings.

Passive-aggressive behavior is expressed in many ways including pouting, sulking, forgetfulness, stubbornness, procrastination, not providing input, the “silent treatment”, resisting or evading requests, creating confusion, purposeful inefficiency, and passive obstruction.

Any of these sound familiar?  They’re are common responses, ones we all exhibit from time to time because they’re easier than confrontation, and require less skill than more positive, assertive ways of expressing ourselves.

While passive-aggressive responses are not the healthiest type of response, as long as it’s not the only way we behave, it can be helpful in the short term especially if there’s a need for acceptance, fear of conflict, dependency, power inequity, or perceived threat.

Consider This
In every organization, there are people who are content where they are, satisfied with the progress they’re making.  They look up one day to check the rearview mirror, and suddenly.…

BOOM!

The change car is right behind them.  Barreling down on them.  Going 2, 3, maybe even 5 times faster than they are.  Urging them to move faster or move to the side.  And you’re driving it.

What’s their reaction?

DANGER!! Don’t Move!
Voila!  There you have it, resistance to change…behavior “that serves to maintain the status quo in the face of pressure to alter it”.[1]

Do you have stories about resistance to change?

Please share…I’d love to hear them!

[1] Zaltman, G., & Duncan, R. (1977). Strategies for planned change. New York: Wiley Interscience

Over the course of this three part blog, I will cover all of the 12 Agile Principles. In this first installment I implore you to stay tuned for all 12, and get to know how principles can impact your team. I believe following these principles is the core of being “Agile”.  It is a topic I am always excited to discuss. How does your group follow the 12 Principles? Is there room for improvement?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
Let’s face it, if we aren’t delivering something of value, what are we doing?

Everyone on the team must understand the value of what they are delivering. As a team, we become “one” focused on our delivery. The value we provide binds us together, and gives us purpose.

Product Owners can provide the team with a Vision to help guide the team to value delivery. Each sprint delivery supports the vision.

We aren’t all lucky enough to work on feature teams delivering software. If you fall in this category, just replace the word “software” with what you do deliver.

Find your value, and deliver small pieces like building blocks.

2. Welcome changing requirements, even late in development. Agile processes harness change for customer’s competitive advantage. 
While this principle seems to invite disastrous changing of scope at any time, this is not the intent. We do not interrupt sprints once they are started, unless it is a dire emergency. There are ways to stop a sprint, which is a topic on its own. What this principle asks us to do, is keep our backlog up-to-date.

If a new feature is requested, it can easily be added to the backlog. If a feature in the backlog is considered to be out-of-date, it can be removed or updated.

As development progress, and more of the backlog is completed, everyone is learning and discovering together. This principle allows us to change, reminding us that the backlog is fluid.

Organizations need to adapt their policies to embrace these changes, or they miss out on a fundamental benefit of being Agile.

Teams should not feel mad, angry or bad because requirements have changed. I often see negative reactions to change, when just the opposite should happen. Through the teams’ continuous delivery, we learn and therefore we adapt.

I like to tell leadership, through your Product Owner we enable the team to build the highest value features at any time. Don’t get locked into years of work in the backlog. Stay engaged, work with Product Owner, keep the backlog alive. Remember the motto “just enough, just in time”, as it will reduce waste by not documenting requirements too far out in the future, that could end-up being changed, or cut altogether.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. 
You’ve decided to follow Agile. You have a backlog, and a team ready to work. Now you just have to get everyone focused on frequent delivery. Organizations like Netflix deliver continuously (see http://venturebeat.com/2014/03/10/continuous-delivery/). However, the rest of us may be still trying to adapt to delivering at the end of a 2-week sprint.

The reason for short time scales is important to understand. Short time scales reduce risk and waste. We test smaller chunks, we get feedback sooner, and overall can react to change easily when we are working in small increments. A short sprint cycle provides plenty of practice, and opportunities for skill and process improvements.

The team needs small stories. Without stories small enough to be built and tested during the sprint, the team will not be able to fit work into shorter time scales. How small? Half a day to two days of effort. Do you shudder at the thought? Developers don’t always like this concept at first, but it is important to try smaller pieces of work. The benefit of small stories outweigh the fact that developers may have to touch code more than once.

Many Agile organizations aim for two week sprints. Some successfully, but new Agile organization may allow teams to work on just a couple of stories that take the entire two weeks; when complete, these stories may be handed over to a QA team. If you are falling into the latter category, there is still improvements to be done to truly benefit from Agile.

In the Scaled Agile Framework, we are introduced to the phrase “Develop on Cadence, and Release on Demand” http://scaledagileframework.com/develop-on-cadence-release-on-demand/. Supporting the notion that the teams’ developed work may sit until the organization is ready for the release, although it is considered “delivered” by the team. Delivery by the team, means the work passed test and is done. Completed work is ready for Sprint Review. The work is demonstrated and feedback is gathered.

4. Business people and developers must work together daily throughout the project.
Oh how I long to click my heels together, and be transported wherever I want. As an Agile organization, you are lucky if everyone is collocated. It is a desire many of us share. The reality is Agile has moved beyond start-ups and web-dev groups. Agile is embraced by organizations large and small; located centrally as well as all over the world.

Using good communication tools can help us feel like we work together, even when we aren’t collocated. The idea of working together daily, allows everyone involved to participate in the Daily Scrum; it allows us to have easy access to each other. No longer are requirements written and “thrown over the wall” to be developed. Developers can share their screens with us, ask questions, get feedback, and quickly resolve issues when Product Owners and business users are readily available. Don’t wait until the Sprint Review to touch base with your team. You will find you have another way to reduce risk and waste.

Use Team Agreements or Team Norms to identify practices for working together. Collocate teams whenever possible. Invite business users to Sprint Reviews. Include times when Product Owners will be available to everyone, as well as when developers can work uninterrupted.

Let me know your comments, and stay tuned for Part-2 where I’ll will discuss the next four Principles.

Being a Product Owner is a really hard job. I have been hearing this for a long time and it has come out in almost all of the retrospectives in one way or the other over the years.  Here are a few recurring themes I hear:

Product Owners and decision – making
I often hear things like – “My Product Owner doesn’t make decisions quickly enough or by themselves. It feels like they have to check with their leaders even before making even the most trivial decisions.”

My questions or thoughts revolve around – is it really a person thing, or is it pointing to the management not providing Product Owner the authority to do so? Is it the management’s mandate for the Product Owner to seek approvals before making any decisions?

If that’s the case then not getting the questions answered in timely manner can impact the completion of work and eventually has a significant impact on Time to Market. It is probably how the organization is structured and the organization probably needs to shift from a Do Agile to a Be Agile mode.

Product Owner is not technical
When did the requirement to be a Product Owner become technical?  A Product Owner doesn’t need to be technical. They need to answer the team’s what’s not really the how’s.

Going back to the Agile Principles: The best architectures, requirements, and designs emerge from self-organizing teams.

Product Owners should not be the ones providing teams the technical direction. They should be able to provide the vision to the teams.

Teams are the ones who make the technical decisions around the design and architecture. The entire team and the Product Owner can look into the various design options and discuss the trade-offs but it is the team that is responsible for the how the implementation will take place and how long would it take.

Product Owner is not available to make the decisions
Being a Product Owner is a full time job. A Product Owner should have ample time to sustainably carry out their responsibilities. If the individual is overworked, the team’s progress suffers and the resulting product may be suboptimal.

At a workshop this week many of the Product Owner attendees were overwhelmed with the length and breadth of the Product Owner role.  They said things like, “As a Product Owner should I be making all the decisions?”, and “Are they really a single- wringable Neck…..but why??”

This role is by no means is an easy role. They have to be constantly engaged in conversations with the stakeholders, keeping a check on the pulse of the market, looking at trends and innovation but at the same time be available with the team to answer all the questions.

I feel very strongly about the Product Owner making the decisions – at a team level the Product Owner is expected to make the decisions. They are responsible for providing the answers to the team. Be the single point of query or decision making body for the team. The Product Owners should be available to the team at least for some dedicated team time or core hours every day.

You should be that leader for the team so the Team does not have to look any further.  The Team can just ask questions of you and get an answer and be sure what is required off them to fulfill the commitment that they made during the sprint planning or the PI planning.

But in all honesty is it Team Vs Product Owner….not really
The memories of best teams that I carry in my heart are the ones in which all of us worked together. We were open enough to call out ‘hey, need you for this and that,” or “I need …….this from you,” and “you need to show up for this meeting and be available at this time…”.

The team (onsite and distributed), Scrum Master and Product Owner all were available during core hours and would address things as they came. Does the level/seniority of Product Owner in the organization matter in the quality of decisions they make? Or is it how much confidence and trust their team and leadership places on them?

Before we start to worry if we have the best Product Owner in the whole world, or if we can be the best Product Owner, it’s important to remember that Product Owners, like the rest of the team, need time and support to acquire the necessary skills.

Everyone has their unique strengths and weaknesses and that’s what we bring to the team. A Product Owner might be great at providing the vision for the product, interacting with the team and stakeholders, but may not be the best at writing user stories.  In areas of inexperience or weakness, the team would pitch in, helping with the work and enabling Product Owner growth.

So, ultimately what matters is the ‘We’ as in team not ‘I’ as a Product Owner.

I used to attend Agile conferences pretty frequently, but at some point I got burned out on them and the last one I attended was a 2007 conference in Washington, DC.  This year, when the Agile Alliance conference returned to the DC region, and I decided it was time to give them a try again.

It’s interesting to see how things changed since I last attended an Agile conference.  Agile 2015 felt much more stage managed than in previous years, with its superhero party, the keynotes making at least glancing reference to it (the opening keynote, Awesome Superproblems, appears to have been retitled for the theme, since all the references in the presentation were to “wicked” problems instead of “super” problems), and making one go through the vendor to get to lunch.  It also seemed like there were mostly “experts” making presentations, whereas previously I felt like there were more presentations by community members.  I have mixed feelings about all of this, but on the whole I felt that my time was well spent.  Although I didn’t really plan it, I seem to have had three themes in mind when I picked my sessions, team building, DevOps and craftsmanship.  Today I’ll tell you about my experiences with the team building sessions.

Two of the keynotes supported this theme: Jessie Shternshus’ Individuals, Interactions and Improvisation and James Tamm’s Want Better Collaboration? Don’t be so Defensive.  I’d heard of using the skills associated with improvisation to improve collaborative skills, but the Agile analogy seemed labored.  Tamm’s presentation was much more interesting to me.  I’m not sure he’s aware of the use of the pigs and chickens story in Scrum, but he started out with a story about chickens.  Red zone and green zone chickens, to be precise.  Apparently there are those chickens (we’re outside of the scrum metaphor here, incidentally) that become star egg layers by physically abusing other chickens to suppress their egg production.  These were termed red zone chickens, while the friendly, cooperative chickens were termed green zone chickens.  Tamm described a few unpleasant solutions (such as trimming the chickens’ beaks) that people had tried to deal with the problem, and ended up by describing an experiment whereby the the red zone chickens were segregated from the green zone chickens, with the result that the green zone chickens’ egg production went up 260% while only the mortality rate went up for the red zone chickens (http://blog.pgi.com/2015/05/what-can-chickens-teach-us-about-collaboration/).  Tamm then went on to compare this to human endeavors, pointing out the signs that an organization might be in the red zone (low trust/high blame, threats and fear, and risk avoidance, for example) or in the green zone (high trust/low blame, mutual support and a sense of contribution, for example), while explaining that no organization is going to be wholly in either zone.  He wound up with showing us ways to identify when we, as individuals, are moving into the red zone and how to try to avoid it.  This was easily the most thought provoking of the three keynotes, and I picked up a copy of Tamm’s book, Radical Collaboration, to further explore these ideas.  The full presentation and slides are available at the Agile Alliance website (www.agilealliance.org).

In the normal sessions, I also attended Lyssa Adkins Coaching v. Mentoring, Jake Calabrese’s Benefiting from Conflict – Building Antifragile Relationships and Teams, and two presentations by Judith Mills: Can You Hear Me Now?  Start Listening Instead and Emotional Intelligence in Leadership.  Alas, It was only in hindsight that I realized that I’d read Adkins’ book.  In this presentation, she engaged in actual coaching and mentoring sessions with two people she’d brought along specifically for the purpose.  Unfortunately the sound in the room was poor and I feel like I lost a fair amount of the nuance of the sessions; the one thing I came away with was that mentoring seems like coaching while also being able to provide more detailed information to them.

Jake Calabrese turned out to be a dynamic and engaging speaker and I enjoyed his presentation and felt like it was useful, but that was before I went to Tamm’s keynote on collaboration.  I did enjoy one of the exercises that Calabrese did, though. After describing the four major “team toxins”: Stonewalling, Blaming, Defensiveness and Contempt, he had us take off our name badges, write down which toxin we were most prone to on a separate name badge, and go and introduce ourselves to other people in the room using that toxin as our name.  Obviously this is not something you want to do in a room full of people that work together all the time, but it was useful to talk to other people about how they used these “toxins” to react to conflict.  In the end, though, I felt that Calabrese’s toxins boil down to the signs of defensiveness that Tamm described and that Tamm’s proposals for identifying signs of defensiveness in ourselves and trying to correct them are more likely to be useful than Calabrese’s idea of a “Team Alliance.”

The two presentations by Judith Mills that I attended were a mixed bag.  I thought the presentation on listening was excellent, although there’s a certain irony in watching many of the other attendees checking their e-mail, being on Facebook, shopping, etc., while sitting in a presentation about listening (to be fair, there was probably less of that here than in other presentations).  Mills started by describing the costs of not listening well and then went into an exercise designed to show how hard listening really is: one person would make three statements and their partner would then repeat the sentences with embellishments (unfortunately, the number of people trying this at once made it difficult to hear, never mind listen.  The point was made, though).  We then discussed active listening and the habits and filters we can have that might prevent us from listening well and how communication involved more than just the words we use.  This was a worthwhile session and my only disappointment was that we didn’t get to the different types of question that one might use to promote communication and how they can be used.

Mills’ presentation on Emotional Intelligence in Leadership, on the other hand, was not what I anticipated.  I went in expecting a discussion on EI, but the presentation was more about leadership styles and came across as another description “new” leadership.  It would probably be useful for the people that haven’t experienced or heard about anything other than Taylorist scientific management, but I didn’t find anything particularly new or useful to my role in this presentation.

Effective communication is important in every aspect of our lives.  When we are talking about situations at work, many issues in the workplace can be avoided if we were better communicators.  This article written by Lea McLeod takes an interesting and engaging look at what is and isn’t effective when communicating. She gives some great insight and tips how to get your point across in a quick and concise manner. Perhaps these habits will help you in both your professional and personal life….enjoy!

https://www.themuse.com/advice/5-habits-of-truly-amazing-communicators

In Diamond in the Rough I talked some about the similarity I found between David Gries’ work on proving programs correct in The Science of Programming and actually doing TDD.  I’ve since gone back to re-read Science.  Honestly it hasn’t gotten any easier to read since I last read it so long ago.  It’s still a worthwhile, though, if you can find a copy. It’s a nice corrective to an issue I’ve seen with a lot of developers over the years: they just don’t have the skills or maybe the inclination to reason about their code.

This seems most evident in an over-reliance on debuggers.  For myself, I only use a debugger when I have a specific question to answer, and I can’t answer it immediately from the code.  “What’s the run-time type of this visitor given these circumstances?” of “Which of the five different objects on the silly call chain was null when it was used?” (that’s a little lazy, since I could refactor the code to make the answer clear without the debugger, but I’m generally trying to find the unit test to write to expose the problem before I fix it, and I don’t want to refactor until I have a green bar that includes the fix to the actual problem). Those are the types of questions I might turn to the debugger to help answer. Particularly when the cost of setting up a test to get that type of feedback is unusually high compared to using a debugger.  This is common when my code is interacting with third-party code in a server container.  Trying to set up some kind of integration or functional test to get the very specific information I want can be a horrible rabbit hole.  (Although it may still be worth setting up the functional test to prove a problem is actually solved.)

So I do recognize times when one can get good feedback more effectively from a debugger than immediately trying to write a unit test or just reasoning about the code one is looking at, but it worries me when the debugger is the first tool a developer uses when something doesn’t act as they expect.  Even when I try asking some developers the questions that I ask myself when trying to understand the problem, the first response is to fire-up the debugger, even if it’s patently not a question that needs a debugger to answer (“What kind of type is that method returning?”  when the actual method declaration is no more than twenty lines down and declares that it’s returning a concrete type).  And, most egregiously, I’ve often seen people debugging their unit tests.

That’s really worrying since the unit tests are meant to help us understand our code.  It concerns me when I see someone’s first response to a unit test failure (even a test they’re just writing) is to run it through the debugger.  Which is not to say that I never do so, but for me it’s always a case of “I know this test failed because this variable wasn’t what I expected it to be.  What was it?”  Again, for me the debugger is a means for getting a specific piece of information rather than something I try to use to help me understand the code.  And that seems a much more efficient and effective way to get the code to do what I want it to do.

The more general case for turning to the debugger seems to be when one doesn’t understand the code.  It’s a little more understandable when trying to understand someone else’s code.  Even then, though, I’m not convinced that the debugger is the best option for trying to really understand what the code is doing.  In a case like this, I’d comment out the code and write unit tests to make me uncomment one small part at a time.  This forces me to really understand what the code is doing because setting up the tests correctly helps me look at the various conditions that affect the code. Gries’ techniques come into play here, too.  It’s unconscious for me now, but the ability to reason formally about the code helps lead me into each new test that will make me uncomment the smallest possible bit of code.

So, how do we learn to reason about our code rather than turning to the debugger as an oracle that will hopefully explain it?  Part of it may be the skills one learns in Gries’ Science, even if they’re not formally applied. The stronger influence, however, may be the way I learned to practice TDD.  I do genuinely test-drive my code and when I first learned TDD it was drilled into me to write my failing test and state why the test would fail.  After not really writing one’s tests before the code, not asking that simple question seems the biggest failure in how I’ve seen TDD practiced.  That might be the better way to learn to really reason about what one’s code is doing.  While I still respect and appreciate the techniques that Gries described in Science, it’s probably both easier and more efficient to learn the discipline of really writing tests before the code, asking the why the test should fail and thinking about it when it fails differently than one expects.

The Missing Piece: Standardized Test Data

The mortgage industry has invested heavily in standardizing the exchange of information, primarily under the auspices of MISMO.  This has made it easier for lenders to switch service providers providing the same or similar services, for technology providers to expand their connectivity and integration offerings to their customer base with limited effort, and for service providers to have a standard approach to communication with their customers.  All this standardization should be and is helpful, reducing technology costs among other things, but it stopped short of the goal by not addressing a key piece: the standardization of testing.

The missing standardization is not related to the process of testing, but rather the data used to verify and validate the process.  Today, each service provider defines their own test cases to be used against their systems.  This has left the testers of the various connections with the unenviable task of constantly adjusting the test criteria to meet those defined for the respective service provider being tested.  Due to the many points of integration and service providers involved with the origination process, end to end testing of an LOS cannot be completed “cleanly” due to the data changes needed to interface with the respective service providers.

The LOS can include upwards of 20 separate data exchange transactions with external service providers.  In lieu of actually testing the system in an end to end fashion, the system testers must constantly adjust the data (usually through system administration functions) to meet the terms of each service providers’ test samples, or create multiple loans that are only testing specific streams of the process to validate selected transactions.  Even something as simple as defining “Joe Homeowner” at “123 Main Street, Fairfax, VA  22030” as the information with which services can be ordered through the test environments, becomes a time saver.

Although standardizing this information, is very different from standardizing the transaction, it is no less important when discussing introducing efficiencies and streamlining the exchange of information.  Standardization of the test data includes defining multiple test names, property addresses, social security numbers, and other common fields to be used in the test transactions.  While each service may require a different set of data, some standardization will go a very long way, particularly when attempting to complete end to end testing of the technology.

Each service provider maintains a different approach to testing.  In some instances, the test data is sent to a production environment, where the specific test data is recognized and treated differently from a production request, e.g., not charging the lender for the transaction. Other providers open their production environment for a limited period, allowing queries to be run without any charges being incurred during the verification process. Still others support a testing environment that includes sufficient information to respond to the transactions submitted with the test data.  The standardization being discussed would not inhibit the selected service provider’s testing methodology, rather it would define, and possibly expand, the data used during the testing activities.

What do you think?  Have you experienced this issue?  Is it time to standardize the testing data across services and providers?

This year CC Pace will celebrate 35 years of business! CC Pace’s corporate office has been located in Fairfax, Virginia since 1983, and while our address has changed over the years, the foundation in which we built our consulting business on has remained the same.

To share some insight on CC Pace we are presenting a three part blog series about the past, present and future of our company.  To learn more about the early years of CC Pace, we interviewed three of our executives: Mike Gordon, our President, Craig Hughes, the Managing Director of Financial Services Consulting and George Perkins, Director of Staffing.  Here is what they shared with us:

What led you to CC Pace?
Mike: In the mid-1970s, there was a company called R. Shriver Associates.  Shriver was out of northern New Jersey and they were a financial services technology consulting firm. In the early mid-70s Shriver decided to open up branches in the East and Midwest, including an office in DC.  In 1978, I was hired right out of college as Shriver’s first full time IT person, their initial hires were more business and management consultants.  My plan out of college was to work for a couple of years and then get my MBA, as my long-term goal was to run my own business.  I took the job at Shriver, thinking working for a very small consulting firm would provide me with a broad range of experiences and business insights that I would not get at a larger firm.  By 1980, Shriver decided that the whole branch strategy wasn’t working, so they decided to sell off the DC branch. The branch manager asked myself and one other person at the company if we wanted to purchase the branch which we did, and that was the beginnings of CC Pace.

Craig:  I was solicited by Rich Lichvar, who I had worked with at Freddie Mac (a client of CC Pace’s since 1980). Rich was at CC Pace (then Cabot Consulting) for a while before returning to Freddie Mac.  He called me one day while I was working for Riggs Bank, he asked me to come talk to Mike Gordon and his partners. Ironically, I already knew Mike from playing poker at Barry Krone’s, who was another Freddie Mac contact.

George: I was working with a recruiter at my job that also supported CC Pace. The position I was in at the time was high stress, poorly managed and very numbers driven, looking for quantity over quality.  I had told the recruiter I was looking to leave my current position. He had worked with Mike Gordon in the past, and knew the culture and environment. He told me he felt CC Pace would be a good fit for me.

20+ years is a long time, describe what CC Pace was like when you started.
George: I actually started in Business Development, but within a few months was recruiting full time. In those days, CC Pace didn’t have a recruiter and Freddie Mac was really heating up from a staff augmentation perspective. Mike Gordon asked if I would help out for a while on the recruiting side. Joanie Cassens was running the Freddie Mac account, and I was supporting her in filling their requirements.  At the same time, our Mortgage and Enterprise Solutions groups were beginning to grow, so the need for someone to focus solely on recruiting and finding candidates increased. It was a great time to be at CC Pace, the company was growing and business was expanding. There was a real element of excitement and pride. We had a great mix of a young, energetic and seasoned team members to take us to the next level. The office was very lively, the culture and environment was great.

Can you recall a major client/project from your early years with CC Pace that you feel has had a great impact on our success?
Craig: Sometime around 1989, Bill Lehman and Mike Gordon selected an accounting system for Commonwealth Mortgage in Boston.  That was the start of our work in the primary mortgage industry. Our client there was Mark Thompson, who remains a source of business for us today.

George: Freddie Mac. They have been a client since our beginning; they were the primary influence for the creation of our staffing division, and we have been a Tier 1 vendor with them for the past 35 years.  The relationship we have cultivated with Freddie Mac continues to evolve and remains strong today.  As a result of this relationship many former Freddie Mac employees have referred us to their new organizations.

What was your toughest challenge on a client engagement?
Craig: I arrived at Fannie Mae to start a project somewhere around 1987, only to learn that the project I had been hired for had been cancelled. The manager, Karen Milan, said she was committed to using me for a project and looked over my resume. She said “it says you know SAS, I need someone to develop some reports for me.” I barely knew SAS, having used it only for simple data extraction tasks. I had to learn SAS on the fly, but went on to develop Fannie Mae’s first consolidated reporting system (pulling data from both the IBM and Data General platforms), their statistics-based approach to selecting loans for post-purchase QC and several other cool things. After my contract was up, Fannie Mae went on to create an entire department to continue doing the things I had started.

What has been some of the biggest changes in your industry since you started at CC Pace?
Mike: When I started, PCs did not exist.  We were a mini computer company so our development work and any corporate computing was done on our Data General (DG) minicomputer, which doesn’t even exist anymore. It cost us over a quarter of a million dollars for the DG and it only provided a fraction of the computing that you get when you can buy a PC or laptop today. The internet wasn’t around for commercial use, so the connectivity and the access to information and applications that the internet brings was not available.   The notion of mobile and other personal devices for communicating didn’t exist.  If you were on the road and had to make an important call, you’d go find a phone booth. From a software development standpoint, the adoption of Agile methods has drastically changed how we go about delivering software.

Craig: Constant regulatory change, but the growth of network services integrated into the Loan Origination System LOS has been a huge change to technology.

 What do you feel are the biggest technology advancements in the last 35 years?
Mike: I’ll go with the Internet.  It has completely changed how business processes can work, with some changes having wholesale effects on some industries, e.g., travel agencies, book stores.  The application systems that we build now are all web-based with the Internet connectivity providing ubiquitous system access.  The rise of social media, enabled by the Internet, has changed how we think and go about marketing.  When we are trying to answer a business question or find a certain type of provider, we are disappointed when the answer doesn’t pop up quickly from our Internet search.

What about the culture at CC Pace has influenced you to stay here for 20+ years?
George:  In the beginning, it was the people, some of my family’s closest friends are people from those early years at CC Pace.  As CC Pace grew, being a part of a growing, vibrant company made it a very exciting and engaging environment.  Over the years the culture has evolved, but having the ability to make a difference, maintain a work life balance, having a say in where the company is going and how it was going to get there, has remained the same. Mike Gordon has developed a culture where everyone is working towards a common goal.  He has done this by sharing information, having an open door policy, and offering constant support to his team.

What, if anything, do you miss about the old days at CC Pace?
Mike: I miss being downtown, although I don’t necessarily miss the commute to get there.  There are so many interesting places to eat, socialize, and explore, and back then, I had plenty of free time on my hands to do all of those things.  Our original office was a brown stone town house that was on 16^th Street, about a block from the White House. The former home of some rich Washingtonian, it was 4 stories high and the various rooms were converted into offices. As the newest employee, my office was in the basement.  What was most interesting about this room is that it had a boarded up doorway that led to a tunnel underneath 16^th Street, it went from the old Russian embassy to my office.  During the Cold War, this was the escape route for the Russians if the embassy was ever under siege.  If you ask me what I least miss about those days, I’d probably have to say the lack of office tools.  I can’t imagine trying to write a proposal without a word processor, but we used to write proposals on a typewriter and make corrections using White Out (feel free to do a Google search on White Out if you’re young and have never heard of the product).

We hope that you have enjoyed an inside look on how members of our leadership team found their way here and how CC Pace began.  As you can see this is a company that has and continues to evolve. Stay tuned for part two of our blog series highlighting our 35^th Anniversary, where we will be sharing the perspectives of current employees on present day life here at CC Pace.

Velocity, the measure of total story points completed in a sprint, is often misunderstood, and used as a “stick” against teams rather than a “carrot”.

I was once asked about trying to prevent a dip in velocity during team member vacations. Today I saw a post in LinkedIn titled “Tips and Techniques for Maintaining Velocity during vacation times”.  The very question of how to keep velocity the same during vacations represents a gap in understanding of both why we use velocity and what velocity is measuring. Velocity is expected to dip when team capacity drops. Otherwise, we are falsely trying to use velocity as a prediction of what can be accomplished in a sprint. Where “management” stresses the need to have a steady velocity regardless of what is going on in a given sprint, it is like using a “stick” to motivate the team. It also encourages “gaming the system”, creating a false sense of security and velocity. We use delivery of quality software as our main measure of success. We use velocity to predict how much work we can commit to in order to become reliable, predictable, and consistent.

Most teams use points to estimate stories, the number of points completed is the teams velocity. The goal is to become predictable and consistent. Velocity is not normalized across teams, and cannot be compared across teams. Once you realize this fact, then it is easier to accept an explainable dip in velocity. Note: If you are following SAFe (Scaled Agile Framework) and trying to normalize points see http://www.scaledagileframework.com/iteration-planning/  In Safe, a 1-point story is normalize, but story points vary from there. A SAFe teams’ velocity should not be compared to any other.

Given a team has been together for at least five sprints, and story points are being used for relative sizing of stories in a consistent fashion, the team’s velocity will begin to stabilize. Good Retrospectives will provide insight into improvements activities that may help increase the team’s velocity a point or two each sprint.

With a stable velocity and team, we can predict what velocity can be achieved for any sprint. If Monday is a holiday, or if one team member is on vacation for the entire sprint, ScrumMasters can help guide the team to not over-commit. Thus supporting a sustainable pace, and exhibiting the true value of velocity as a measure.

Let’s take a look:

Team Wolf

Team Wolf has 6 members, and a velocity of 40 for a two week sprint. I calculate capacity (the number of hours available to work in a sprint) at 6 hours per person, per day. For Team Wolf, a 10 day sprint has 360 capacity hours.

One bank holiday during a sprint

Capacity is 324 hours, (6 * 6 * 9) resulting in a 10% lower number of hours in which to complete the sprint’s work. I would encourage the team to commit to approximately 10% less work and aim for a velocity of 36 points.

One member on vacation for the entire sprint

Capacity is 300 hours (5 * 6 * 10) resulting in a 17% lower number of hours for a sprint. I would encourage the team to commit to approximately 17% less velocity, or 33 points.

Velocity dips can happen anytime for a number of reasons. A planned dip is not something to beat a team up over. Achieving the teams’ committed velocity is an excellent carrot. Reward teams, and celebrate successes.

Notes from Agile 2015 Washington, D.C. 

Having lived in Washington DC area for over 25 years, my experience caused me to presume that the majority of the audience at the Agile 2015 Washington DC would primarily consist of people working in the public sector, given our geographical proximity to a long list of federal agencies. It was not unrealistic for me to expect that the speakers at the conference might tailor their presentations and discussions to this type of audience. The audience actually turned out to be quite diverse, rendering my assumptions inaccurate. However, I could not help to feel somewhat validated after listening to the first key note speaker.  Indeed, the opening presentation by Luke Hohmann entitled “Awesome Super Problems” focused on tackling “wicked problems” such as budget deficits and environmental challenges. Wicked problems, as described by Mr. Hohmann, are not technical in nature and cannot be solved by small Agile teams of 6-8 people. These problems deal more with strategic decision-making that may result in long-term consequences, intended as well as unintended. They impact millions of people and they require broad consent as well as governance. Hailing from the San Jose, California, Mr. Hohmann discussed how implementation of Agile methodologies helped the city tackle some “wicked problems” such as a budget deficit of 100 million dollars.

Planning and Executing
Solving major problems such as budget shortfalls generally require a great deal of collaboration between stakeholders with competing priorities. Mr. Hohmann stressed that the approach should focus on collaboration over competition, or in Agile terminology, “customer collaboration over contract negotiation”. Easier said than done? Maybe… To help facilitate this collaboration, Mr. Hohmann assembled a conference of public servants such as city planners, police and fire chiefs, and other community leaders. There were several discovery sessions where people could get answers to questions like how much money would be saved if the fire department removed one firefighter from their teams and what impact to safety that may entail. The group was broken down into small tables of no more than 8 people and one facilitator provided by Mr. Hohmann. The group was presented with the list of major budget items and subsequently was compelled to engage in budget games  in which participants were basically bidding to get their high priority budget items included in the next budget and negotiate cuts by trading these items. Afterwards the players had a retrospective and offered feedback.

Retrospective and Outcome
Feedback provided by the participants showed that competition was replaced by collaboration. Participants tended not to get into heated arguments because the games inherently encouraged compromise. Small groups helped cut down on distractions and side conversations. The participants also reported that the game was fair since every player possessed equal bidding power. Interestingly, the final outcome resulted in surprising consensus over the budget items, as the majority of the participants actually ended up prioritizing their items very similarly after the competition aspect was removed. The “democratic” aspect of the collaborative approach helped eliminate animosity and partisanship which are not uncommon, as have been witnessed in the U.S federal budget negotiations. This experiment seemed to yield the desired outcome of tackling the imbalanced budget and was touted as a success, attracting attention of more San Jose residents.

Scaling
To tackle other public issues such as school overcrowding and water shortages, Mr. Hohmann attempted to repeat the process, but the number of participants has increased to the point where a large conference hall was needed. In order not to upset the budget by renting a giant conference hall, Mr. Hohmann and the local government set up an online forum that accepted a virtually unlimited number of participants, yet still assigning them to groups of about eight people and increasing the number of groups. The participants played other games such as Prune the Product Tree which basically involves prioritizing the list of problems the public wants to tackle. The feedback was even more positive as the majority of the participants actually preferred the online setting even more. They reported even less distractions. The data was easier to collect and aggregate, giving the participants almost an immediate view of how the game was progressing and how the priorities were moving.

Conclusion
One main takeaway I got from Mr. Hohmann’s presentation is one of encouragement to be creative. Mr. Hohmann stressed the importance of focusing on what he described as “common ground for action”. The idea is to focus on generating a list or backlog of actionable items. The process or exercise to get to the desired state can vary, and Agile methodologies can help folks get there, even when tackling wicked problems.

External Links:
http://www.innovationgames.com/budget-games-guide/

http://www.innovationgames.com/prune-the-product-tree/

Further reading:
http://conteneo.co/san-jose-residents-play-4th-annual-budget-games/

I’m often asked how to create empowered teams.  The question usually includes the exclamation “I told them they’re empowered, but they’re not acting like it”, and an expectation that I’ll be able to provide a successful formula or recipe that can be replicated.  Well, I don’t have a specific formula, but here are some important concepts I’ve learned.

Empowerment is a two-way street
It’s not enough to anoint people or teams as “empowered”, they need an environment that is congruent with empowerment, and they have to accept the mantle of being empowered.

Providing an empowering environment is the responsibility of leadership, top-to-bottom in an organization; accepting the mantle of empowerment is the responsibility of each individual and team.

As individual team-members go, so goes the team
Even in exactly the same environment, different teams will likely exhibit different levels of empowerment, because each individual team members’ level of acceptance is different.  Personal style, culture, history, experience, values, comfort with ambiguity, and risk tolerance all affect an individual’s willingness to “be empowered”, and the extent to which they exercise that empowerment.

While you and I will vary in how we embrace empowerment, we both need the same conditions to be met.  To feel and act empowered, we need:

Clarity – I am clear about what needs to be accomplished (intent), and why it’s important (value), even if the how is uncertain.  I understand the purpose and what success looks like.

Ability – I have the knowledge and skills to do it, even if I don’t have specific experience.

Agency – I have the authority to make decisions about how I do it.

Safety – I feel safe to do it. To make decisions and act; to fail so I can learn; to communicate honestly and openly.

Belief – I believe I can do it. I have self-confidence and self-efficacy.

Interest – I am interested in doing it.

Creating an Empowering Environment
Julian Rappaport, in “Studies of Empowerment” (1984) said “it is easy to define empowerment by its absence, but difficult to define in action as it takes on different forms in different people and contexts.”

Regardless of how it’s accomplished, successful empowering environments satisfy the conditions identified above, and actively encourage and support individuals to grow in these areas.  There are underlying themes that work from one organization to another, including:

• Don’t solve people’s problems – help them learn how to solve their own
• Change the language – thoughtfully replacing key phrases can have a huge impact
• Truly believe in the good intent of others – people don’t set out to do the wrong thing
• Make learning important – not training, although that’s a component, but learning by doing
• Give permission to fail –we learn the most when we’re free to fail
• Provide opportunities to succeed – it builds confidence
• Decisions are choices, accept the consequences of yours – and show others how to do the same
• Be curious – but don’t question, it erodes confidence
• Become story tellers – stories inspire and provide context and clarity
• Set reasonable boundaries – and help others learn to expand them to broaden their sphere of control
• Expect honesty – not compliance
• Walk your talk – be visible and show how it’s done
• Help them learn to walk – challenge people to step outside their comfort zones, and support them

For a story of what Stephen R. Covey calls “the most empowering organization I’ve ever seen”, check out the book Turn This Ship Around by L. David Marquet.

I’d love to hear your thoughts….how do you help create a sense of empowerment?

As described by Jeff Sutherland, the Product Owner (PO) is “the person responsible for managing the Product Backlog so as to maximize the value of the project.  The Product Owner is responsible for representing the interests of everyone with a stake in the project.”

The Product Owner is a key role in the Scrum framework.  It’s a tough role, and people often have difficulty embracing it.  Today, I’ll discuss some of the common questions we get from POs in the government arena.

What’s my Role?
A Product Owner maximizes ROI by:

• Identifying product features
• Prioritizing features and other work
• Ensuring a steady flow of value by choosing the most important work for the next sprint
• Continually re-prioritizing, elaborating, and refining the list

A Product Owner guides and supports the team, keeping them from thrashing, by:

• Continually painting a picture of the destination (the vision and context)
• Ensuring a steady flow by “feeding” the team ready work
• Being available and actively interacting with the team on a daily basis to answer questions and provide guidance
• Making decisions to keep the team moving forward
• Providing a link between business stakeholders and the team
• Providing feedback as a sprint progresses
• Signing off on work results
• Providing a single voice to the team on product priorities and decisions

A Product Owner represents stakeholder interests by:

• Actively interacting with stakeholders to identify needs, gather information, and solicit feedback
• Ensuring the product creates value for stakeholders

What Skills do I need?
A Product Owner has, or develops, deep knowledge and competence in:

• Business domain and subject matter expertise (SME)
• Understanding and empathy with the customer, business, and market
• Weighing risks and making timely decisions with available information
• Conveying vision, setting context, and contributing to team and stakeholder understanding by “telling the story” of needs, behaviors, and success criteria
• Understanding and incorporating appropriate techniques to communicate with the team and stakeholders
• Understanding and use of conflict resolution techniques
• Understanding of group dynamics and complex change
• Negotiating priority and trade-off decisions
• Facilitating discussions and decisions
• Sensing and scanning inward, understanding and providing what the team needs to be effective
• Challenging the team to improve
• Sensing and scanning outward, understanding and delivering what stakeholders want/need
• Managing stakeholder expectations

What’s my Title?
“That which we call a rose, by any other name would smell as sweet” – Shakespeare

Scrum does not specify who should play the Product Owner role.  It only provides a general description of the role and responsibilities, and identifies a framework of ceremonies and artifacts that guide what to do.

So, the PO can be anybody (e.g., a Business Analyst, a Product Manager, or a Program Manager commonly play the PO role), as long as they have the necessary skills and time to dedicate to the role.  How they fulfill the responsibilities of the role will vary from person-to-person based on experience, need, and organization culture, structure, and constraints.

For smaller projects/product lines, with fewer teams, the PO responsibilities can be handled by one person (e.g., a product manager, senior business analyst, or program manager).

In larger organizations, or larger programs/product lines, the PO responsibilities are often divided because one person won’t necessarily have the skills or sufficient time to fulfill the needs of the role.

A common division occurs at the intersection of the “inward”, team-facing, tactical responsibilities (handled by a business analyst) and the “outward”, customer-facing, strategic responsibilities (handled by a Product Manager or Program Manager).  It’s important to remember that even if there is a division of labor and responsibilities, there will likely be some overlap and constant collaboration and “mind-melding” is required.  This maximizes transparency, minimizes hand-offs, and ensures congruent decision-making.   From the team’s point of view, there is still one PO, a “single voice” providing priority, information, and decisions.

Why is the PO role so hard to grasp?
Product Owner is a role, not a title.  A “job role” is a function that’s performed, a description of the part a person plays.   A “job title” is the name given to a position within a company, one that typically implies stature or hierarchy.

Traditional job titles have evolved over the years to align with specialized skills, collapsing roles, responsibilities, and skills into common titles (e.g., business analyst, project manager, and tester).  These tried-and-true titles have a long history, and are recognized, hired, measured, compensated, and rewarded similarly across the industry.  Many of us define ourselves by our job titles; they represent status and stability, identity and importance, achievement and acceptance.

Then along comes the Product Owner.  A new role with skills and responsibilities that not only don’t map cleanly to a job title we’re familiar with, but actually overlap several (e.g., product manager, program manager, project manager, business analyst).  Our axis shifts, our identity is challenged, and we sometimes find ourselves adrift in ambiguity.  To compensate, we grasp for a detailed description and firm boundaries to help provide clarity.

This is a common “shu” response when acquiring new knowledge, especially true when that knowledge comes with a significant shift from what we’re used to.   As we learn and become more comfortable, the need for boundaries lessens and our tolerance for ambiguity increases.   Mentoring and coaching can help support individuals through this uncertainty.

How is a government PO different?
The Product Owner role itself is not really any different in the government….the responsibilities are essentially the same, as are the skills required.

What makes the government setting unique is the combination and degree of:

• organization structure
• funding strategies and acquisition constraints
• compliance requirements
• technical complexity
• requirements complexity

I’ll talk briefly about how organization structure affects the PO role; the other factors are outside the scope of this blog.

Although the size and approach to government IT programs/projects is changing, at present they still tend to be on the large side.  The number of different agencies and/or vendors involved, the number of teams, and where work is performed are all factors in determining complexity of the program structure.

It’s typical for government agencies to rely heavily on vendors to “design-build-test” their solutions, and keep the requirements definition and user acceptance (UAT) in-house.   Subject matter expertise is split between government staff, who primarily have business domain knowledge and expertise, and vendor staff, who primarily have technical domain knowledge and expertise.

Since a key skill set for the PO is deep business domain expertise, it makes sense then for the PO to be from the government staff.  And since the PO is responsible for making scope, schedule, and budget trade-off decisions, the ideal candidate would again be from the government staff.  The government program manager is often a good choice as the PO, but care should be taken to adequately consider who is best positioned to handle challenges such as those identified below.

Typical, traditional government practices transfer risk and responsibility for failure to the vendor, but having the PO from the government staff means responsibility for successful delivery shifts to the government, as they can no longer claim to not be in the know.

PO Challenges in a Government setting
There are a number of common challenges that can impact establishing strong and effective Product Ownership of government projects and products.  The considerations listed here are not all unique to a government environment, but often occur at a higher rate.

Key considerations include:

• Time commitment – being a PO is a full-time commitment, not something that can be done “off the side of the desk”. Most of the considerations listed here affect the time commitment required by a PO.  Environments where all of these factors occur will significantly impact a PO’s productivity and effectiveness.
• Distance – remote teams increase a PO’s workload. This increase is often not considered when determining PO/team ratios.  There are tools that can help, but it just takes more time and effort to establish a rapport and communicate with teams and stakeholders who are physically remote from the PO.
• Hierarchical structures – power dynamics and hierarchical lines of authority can hamper a PO’s ability to make timely decisions.
• Frequently changing vendor teams – increase a PO’s workload, requiring more support to build intellectual knowledge and onboard teams.
• Multiple projects/products – one PO, one backlog, one team is a rule of thumb. That will vary somewhat depending on their maturity, the team’s maturity, and the type of work being done.
• Customer availability – PO’s need timely access to end-users and other customers/stakeholders to be effective. Generally, the less customer availability, the more PO time is required for coordination.
• Supportive environment – PO’s need support from leaders and sponsors to reinforce decision authority and help remove organization impediments.
• Acquisition constraints – PO’s in the government are sometimes also the COR (Contracting Officer Representatives). Their SME knowledge makes them a good choice for this, but increases their workload, especially during pre-award activities.
• Governance/Compliance – heavy compliance usually means a PO spends less time on CVA (customer value add) activities, and more time on BVA (business value add) activities.

So there you have it….leave a comment, I’d love to hear your thoughts!

We recently ran into an issue with ASP.NET authentication that I thought I would share.

The Setup 

We’re running an ASP.NET MVC 5 web application which uses Microsoft ASP.NET Identity for authentication and authorization. We allow users to choose the built-in “Remember Me” option to allow them to automatically login even if they close the browser. We first set this to expire after 2 weeks, after which they are forced to login again (unless you’re using Sliding Expiration https://msdn.microsoft.com/en-us/library/dn385548(v=vs.113).aspx)

When we first implemented this feature, users would complain that they had to keep logging into the site, despite checking the “Remember Me” option. We first made sure that within the Startup configuration, the CookieAuthenticationOptions.ExpireTimeSpan was explicitly set to 2 weeks (even though that is the default).

After some more troubleshooting and, of course, a stackoverflow hint, we discovered the problem.

What we checked

1. We checked to make sure the browser cookie that contains the encrypted authentication token had an expiration date (instead of “Session” or “When the browsing session ends” in Chrome).

In our case the cookie contained the expected expiration date:

2. We observed that the “Remember Me” automatic login worked throughout the day, but typically stopped working the next day.

So what happened every night that might trash or invalidate our authentication token? We discovered that the Application Pool for our IIS site was getting recycled nightly.

​This alone did not seem to be the culprit, since a user should still be able to automatically login (if they choose to) even if the app pool restarts. Taken a step further, even if the server restarts, this functionality should still work. What about a load-balanced environment where the user doesn’t even hit the same web server? This should all be transparent and the “Remember Me” option should just work.

3. We searched the web for scenarios where a user must relogin after a server restart and came across this article: http://stackoverflow.com/questions/29791804/asp-net-identity-2-relogin-after-deploy

This seemed to be the root of the problem – we needed to configure the machinekey settings in order to maintain consistent encryption and decryption keys, even after a server or app pool restart. If this is not set explicitly, new encryption/decryption keys are generated after each restart, which in turn invalidates all outstanding authentication tokens (and forces users to login again).

The Solution

It turns out that it is easy to generate random keys in IIS, which will set the values directly in your web.config file:

Now we can store the consistent keys in our web.config file and not worry about invalidating a user’s authentication token, even if we restart, redeploy or recycle the app pool on a consistent basis.

In a load-balanced, web farm environment, this setting is critical to allow users to bounce between load-balanced servers with the same authentication token. You just have to make sure that the same encryption/decryption keys are used on each website (configured via the machinekey setting).

If you’re considering using Azure Web Apps, this is transparent since “Azure automatically manages the ASP.NET machineKey for services deployed using IIS”. More details here.

That is a subject for another day.

Last month I had the opportunity to attend my first ever Coaches Retreat. The retreat was made up of about 80 participants. Preparation for the retreat started months in advance, even for us participants. First we were requested to send in an introduction poster. Second, we were asked to suggest topics for the retreats. As I had never been to a retreat like this before, I didn’t exactly know what to expect. So I thought I’d share my experience of the event.

One of the first things we did after the retreat got going was to form teams around topics. There were plenty to choose from, after all the customers (us attendees) had sent them in. We “self-organized” in teams around topics we were passionate about. I became part of a team organized around the topic of Virtual Teams. Next we set off to plan for three 180 minute sprints. Our team was awesome. We picked a team name; stormed a little, formed a little… We created a vision, a backlog, and committed to sprint 1. Of course we did all the ceremonies for each sprint. Each team’s sprint review was in front of the entire group which provided an opportunity for feedback from customers!

Three days of working with peers from near and far led to each team providing a “product” related to their selected topic in 180 minutes. Wow, what an experience! What a result!

My experience of the retreat was not only a learning experience, but a growing experience. I experienced true team self-organization, and boy was it cool. Within my team, I learned that utilizing Scrum Values (Focus, Courage, Openness, Commitment, and Respect) are as important as the Principles and Manifesto. As our team went through storming to norming, we demonstrated these values. We talked about the work ahead of us, and how we were feeling. Yes, feeling! Our volunteer Scrum Master wasn’t sure she was in the right role; I wasn’t sure I was with the right team. I felt that our team more than any other practiced what we preach as ScrumMasters, Coaches and Trainers. I credit each one of us with following Scrum Values to get through storming quickly. In seeing everything the other teams delivered I gained a set of tools I can utilize anytime. I grew in my sense of belonging to the Agile community, and pushed through my fear and lack of control by exhibiting Scrum Values, and being engaged with my team. The retreat was an opportunity for me to continue a journey of learning and growing, all while making new friends.

Here’s to Team Dysfunction!

Sometimes when I have wait time, I pull out my phone and play games.  Nothing sophisticated or too demanding, just something calming that allows my mind to wander.

Last week I flew to DC, and, once seated, found myself waiting for everyone else to board.  So I pulled out my phone and played a round or two of “Swiped”….what can I say, it’s free and I like the bright colors.

As I played, it dawned on me this simple, mindless little game reinforces some big concepts; concepts that influence our behavior and help define our comfort with change:

Perfection slows me down
Trying to optimize each move by swiping all possible jewels takes longer and may result in a lower score.  It’s a tradeoff that needs to be consciously made.  For you, is it more important to finish everything perfectly, or finish enough and move on?

Smaller isn’t exciting, but it adds up
In baseball, hitting a “home run” is exciting and adds to the score quicker.  It also makes for bigger heroes.  Yet looking for that perfect ball allows a lot of balls to go by that are “good enough” to hit and keep the game going.  How ‘bout you….do you go for the small, sure hit, or do you wait for the home-run ball?

The closer I get, the less I see
Perspective makes a difference in situational awareness.  Holding the phone close, or focusing too much, or too early, on a specific move keeps me from seeing other possibilities.  Holding it a little farther away allows me to stay aware of the whole, while still seeing details and possibilities for the next move or two.  What perspective is best for you?

Gold is dazzling, but isn’t necessarily the best move
Those bright and shiny gold gems really draw my eye, sometimes distracting me from seeing different options, and making better choices.  Do you find yourself drawn by the gold?

Sometimes the best move is any move
Start somewhere, deal with what’s in front of you, see what develops, and do the best you can to keep moving forward.  How about you….do you pause to consider options, or do you make quick decisions and move forward?

Send me a comment…I’d love to hear your thoughts!

The warm weather is upon us and if you haven’t already, now might be a good time to plan your summer vacation.  We surveyed the CC Pace staff about their favorite vacation destinations. The results range from the Jersey Shore to all the way across the pond.  Here, in no particular order, is a list of the “Top 11 Favorite Vacation Spots for the CC Pace Team” (10 just wasn’t enough):

1. Ocean City, NJ – Two of our teammates enjoy the beach and boardwalk of the Jersey Shore. This beach offers so much to do from golfing to boating, and is also known to have great seafood!
2. Newport Beach, CA – With West Coast roots, we have one employee who tries to make it back to this beautiful beach at least once a year.
3. Hatteras, NC – With its gorgeous beaches and laid back feel, Hatteras is a great place to chill with family and friends.
4. Block Island, RI – This small little island off the coast of Rhode Island is purely a hidden treasure. It has that charming New England feel along with great beaches, this gem is a must see!
5. Tampa, FL – If you like to fish, this may be the perfect destination for you! Tampa also offers great food and the opportunity to experience some Cuban and Haitian culture.
6. Virginia Beach, VA – Just a short drive away from life in Northern Virginia is Virginia Beach! This coastline city offers a great boardwalk and some wonderful restaurants.
7. Home, Staycation – That’s right, those who travel during the week enjoy relaxing at home to decompress. But, if they had to jump on a plane, they would head straight to San Francisco, California – a fascinating city with something for everyone!
8. Riviera Maya, Mexico – This adventurer likes to explore the Mayan ruins, zip line over the jungles, and do some underground kayaking!
9. Lake Washington, WA – In the summer, this beautiful lake offers the perfect environment for relaxation. In the cold winter months, this employee likes to soak up some rays in Mexico.  Not only is it a nice break from the cold but you can land some great deals.
10. Anywhere International – This world traveler likes to hit different places as much as possible. One favorite is Italy…Rome, Venice, Tuscany, truly a magnificent place worth visiting more than once!
11. Bethany Beach, DE – Sun, surf, and pure relaxation. The sights and sounds of the beach offer a truly calming experience that is much needed during a vacation.

Whether your ideal vacation is full of action and adventure or total relaxation by the water, it is important to take time to de-stress and recharge.  Proven studies have shown that individuals who do not take vacation are less productive and can burnout much quicker than those employees that take a break.  So, now is the time to go explore, relax and make some memories!

In a previous blog I shared how unfinished tasks tend to constantly interrupt our thoughts, create anxiety and affect our productivity. Research has proven that in human endeavors, once expectations have been set, our brains seek a conclusion. If that conclusion is not forthcoming, the brain “stays open” to receive it. Zeigarnik effects result from our mind’s tendency to seek conclusion: when leaving tasks unfinished to focus on something else, we experience anxiety and intrusive thoughts about the uncompleted tasks. Since multi-tasking is simply diverting our attention from one task to another (basically making the new task an interruption), our brain won’t allow us to fully focus on the new task because we have left the previous one uncompleted.

Kanban core practices not only help alleviate these effects, they can spin the Zeigarnik effect on its head and use it to our advantage. Here are several ways how this works:

• One of the Kanban practices is to “Limit Work In Progress (WIP)” based on available capacity to complete the work. This practice supports our brain’s natural inclination to seek closure by finishing what we started.
• Another core practice is to “Manage Flow”, meaning that we want to reach the optimum cycle times possible for everything we do. Besides a definition of “Done” teams define a definition of “Ready” that helps prevent starting on work they could not complete due to missing information or unavailability of subject matter experts (SMEs) along a value stream.
• In the event that information or people are not available, the affected work item is blocked visually indicating that work cannot continue until the blocker is removed. The physical act of blocking a work item cancels Zeigarnik effect by providing the closure our brains seek.
• Author and psychologist Perry W Buffington described the Zeigarnik effect by stating that people tend to remember negative experiences and feelings longer than positive ones. In our world this means that we hear more often from our stakeholders about what we haven’t done for them and less about what we delivered. Drawing upon this phenomenon, in our Kanban consulting practice we coach delivery teams how to consistently review with customers how delivered work is always completed at the expense of other work not being done. This leads to better prioritization, less escalations and minimizes interruptions.  This approach is part of two other Kanban practices: “Develop Feedback Loops” and “Improve Collaboratively, Evolve Experimentally”.

Do you have a lot of unfinished business like a multitude of projects, tasks, and priorities that constantly change, requiring you to stop working on something and start working on something new or on something that was already on hold? Is the unfinished business (The Zeigarnik Effect) hunting you? Do you know how to forecast the capacity you or your team has and how to improve it?

High performance or high productivity require staying focused and avoiding multi-tasking or disruptions. Kanban practices can help you and they are easy to adopt alongside any other processes you already have in place. Our Certified Kanban Foundations Course will help you get started. Let us know what questions you have.

_____________

References

Zeigarnik, B.V. (1927). Über das Behalten von erledigten und unerledigten Handlungen (The Retention of Completed and Uncompleted Activities), Psychologische Forschung, 9, 1-85

Perry W. Buffington, Cheap Psychological Tricks (Atlanta, Georgia: Peachtree Publishers Ltd., 1996), pages 93-95.

As an Agile enthusiast, trainer and coach I’m pretty passionate about being Agile regardless of the specific framework being followed. In fact, my passion lies in the culture of being Agile, rather than a dogmatic adherence to a framework.

Following a Framework

A dogmatic approach to a framework may work well if you are a “.com”, start-up, or other application development shop. But, for those of us working with large corporations a dogmatic approach feels impossible. Here are a few of the reasons why:

• Team members are not co-located
• Teams are not developing software
• Team members are not fungible
• Teams cannot deliver anything fully functional at the end of a sprint (1 – 4 weeks)
• Teams rely heavily on other teams to deliver components, and struggle with dependencies
• Organizations have a legacy structure that doesn’t support being Agile
• Organizations want the teams to be Agile, but they don’t want to change anything else

I fully support adopting a framework, so don’t get me wrong. Organizations should try to adopt as much as possible of their chosen framework, and specifically note exceptions acknowledging deviations from a given framework. However, before the organization gets concerned about the framework they are trying to follow, I ask them to look at the Agile Manifesto and Twelve Principles. How much cultural change is the organization willing or able to accept in order to adopt a framework? As true agility requires both, a change to the new framework and a change in culture.

Cultural Change
When the “gurus” got together in Colorado, they not only defined the Scrum Framework, they created the Agile Manifesto, and Twelve Principles. These two items identify the Culture of Agile. To truly be Agile, organizations must work on the cultural change required regardless of the framework.

From the Manifesto:
Does your organization really put Individuals and Interactions over Processes and Tools?

Carte blanche rules for processes and tools don’t always work for everyone within the organization. Some tailoring must be done to truly be effective. Marketing teams may not need to use the same story writing and management tools as Software Teams.

Do they favor Working Software (Value Delivery) or Comprehensive Documentation?

Note: For non-development teams, I prefer to consider what “value” the team is delivering as working software does not apply.

This is not an excuse for skipping documentation all together.

Does your environment allow for true Customer Collaboration over Contract Negotiation?

Or do you have a hard time trying to figure out who is the recipient of the value you are delivering? A culture of “us versus them” may keep workers away from collaboration

Does the organization Respond to Change over Following a Plan?

Or are we all so worried about scope creep, we have a rigorous change policy? Or has the pendulum swung the other way, and you’re experiencing the “Chicken Little -sky is falling” scenario all the time?

Acknowledging the Agile Manifesto and how an organization may adopt their culture to it, is one of the first steps to agility.

Twelve Principles
To be honest, I find the majority of teams I work with have no understanding of the 12 Principles of Agile. How can that be? Does leadership really believe a framework will work without other changes? Yes, it is hard. Yes, someone will always be unhappy. Welcome to the real world.  If you fail at adopting Agile, and you haven’t tried to change culturally, is it really Agile that doesn’t work? Are teams working to be Agile, while the rest or the organization continues with business as usual?

Think of the simple scale from “Somewhat Agree to Somewhat Disagree”, and for each of the Principles score your organization.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (or just value delivery)

This allows our customers to see steady and ongoing progress towards are end goal.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Changes of scope may have an impact, but we need to quit complaining about change.

3. Deliver working software (value) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Reduce risk, increase collaboration, break work down into small pieces, and get feedback after each delivery.

4. Business people and developers must work together daily throughout the project.

If the team doing the work has no access to the recipients of the value, are you playing the “telephone game” with requirements and feedback?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile teams are self-organizing, self-managed, and empowered to do what it takes to deliver quality value at regular intervals. If you’ve truly hired good people who want to do a good job, why micromanage them? Empower your folks, and see what happens. With any luck teams will learn to pick up the stick, and run with it.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Skip multiple emails, and meet face-to-face even if it is over the internet!

7. Working software (quality value) is the primary measure of progress.

If you’re not creating software, deliver small pieces that act as building blocks towards completing your value delivery.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A little extra time here and there is okay. However if working 50 – 60 hours is the norm, it’s hardly sustainable.

9. Continuous attention to technical excellence and good design enhances agility.

Going faster doesn’t cut it if quality drops. The focus should always be on delivering quality.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Do you remember the 80/20 rule? We have a phrase “no gold plating”, so focus on what really matters to the 80%.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Learning new practices, and engaging regularly to ensure the foundation is sound enables teams to take advantage of emerging technology and practices.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Without continuous improvement, being Agile slips further and further away from reality.

Summary

Cultural change is key within organizations in order to really support the Agile Manifesto and its Twelve Principles.  Where does your organizations culture fall when using the Manifesto’s scales, and the Twelve Principles? Work to move the pendulum a little at a time as needed. The origins of Agile lie not in black and white answers but in collaborating to do what is best in our drive to deliver value. Your customers will be happy, and you’ll retain employees and keep them and shareholders happy.

As a developer, I tend to think of YAGNI in terms of code.  It’s a good way to help avoid building in speculative generality and over-designing code.  While I do sometimes think about YAGNI at the feature level, I have a tendency to view the decision to implement a feature as a business decision that should be made by the customer rather than something the developers should decide.  That’s never stopped me from giving an opinion, though!  Until recently, my argument against implementing a feature has generally been a simple argument about opportunity cost.   Happily, Martin Fowler’s recent post on YAGNI (http://martinfowler.com/bliki/Yagni.html) adds greatly to my understanding of all the cost that not considering YAGNI can add to a project.  Well worth a read regardless of whether you’re a developer, Product Owner, Scrum Master or fill any other role.

In a business world where people are always moving on to new opportunities, what makes someone stay with one company? What makes you say, ‘I think I want to learn and grow with this company’?

This year CC Pace celebrates the 5 year anniversary of two employees, Jenna Bayer and Ashok Komaragiri.  Jenna is our Corporate Marketing Manager and Ashok is a Technical Consultant in our Enterprise Solutions practice. CC Pace President, Mike Gordon, recognized both at our Staff Meeting in March 2015.  He spoke about each regarding their accomplishments and how they have grown over their tenure with the company.  Mike then presented them each a service award and the traditional CC Pace gag gift.  We wanted to find out from Jenna and Ashok what drew them to our organization, what have they learned here and what do they see in their futures at CC Pace.

Why did you chose to join CC Pace?

 JENNA: Ultimately, I was drawn to the culture of CC Pace. I liked the work-life balance they offered and the fact that there were a number of employees who had been there for a decade or longer. At the time of my hiring, I believe the average tenure was around 11 years. To me, that said there were opportunities for growth and indicated that CC Pace must be a great place to work to have such a low level of turnover.

ASHOK: I first heard of CC Pace from a friend of mine who had worked with them very closely on one of their earlier projects. He spoke very highly about the standards set by CC Pace on that project, and the technical skill set they brought with them to the table. My friend mentioned how without ever losing focus on the client’s needs, the CC Pace team always delivered efficient solutions to complex problems. The fact that they were also at the forefront in using Agile Software Development Methodologies greatly caught my attention.  When I was looking for a new opportunity, I was very fortunate that my friend could refer me to CC Pace.

What have you learned while at CC Pace?

JENNA: I’ve learned so much in my 5 years, but I think the most impactful lesson I’ve learned is to not be afraid to take risks or make mistakes. Having the freedom and support from upper management to try things out and really be able to figure out what works, (along with what doesn’t) has taught me more than if I had it all spelled out for me.

ASHOK: The most valuable skills I have learned are the practical application of Agile Methodologies combined with Engineering Practices like Test Driven Development (TDD) and Extreme Programing (XP).

What is one of your most memorable moments?

 JENNA: It’s hard to pick just one, but October 2013 when our new website launched was definitely a highlight. It was my first time working on a large marketing project and I was so excited to be a part of it. It was a much larger project than anticipated, but I learned a great deal and it was a lot of fun to see the final product!

ASHOK: The most memorable moment for me so far has to be when we went live with both the Student Tracker for High Schools Rewrite, and the Student Matching applications at the National Student Clearinghouse. It was very gratifying to hear from a client how we greatly improved their productivity and what used to take them a month to process now takes only a few hours. In our world that is a huge success!

What are one or two of your future professional goals that you would like to achieve while working at CC Pace?

 JENNA: I’d definitely like to see our blog readership take off (shameless plug: if you haven’t subscribed, now would be a great time to do so!) and I am looking forward to being a part of increasing our marketing efforts.

ASHOK: Personally, I look forward to continue to deliver quality projects by always focusing on clients’ needs and adhering to Agile Principles.

As we look forward to seeing what these two accomplished individuals bring to their futures here at CC Pace, we see that having a work environment that encourages growth and learning are strong factors in why employees make the decision to stay.

pictured: Ashok at bi-annual staff meeting

When an organization decides they want to “Go Agile”, they usually go through a multitude of changes before they get into a rhythm of the method(s) they have decided to use.  Once a team gets into a rhythm of ‘going’, or just doing, they will most likely be so engrossed that they forget to look up and see where they are.  However, it is important that they stop at some point to examine how things are going overall in their Agile journey and whether or not their method(s) are working for them.

The most popular framework that teams choose when first moving toward being Agile is Scrum.  In order for a team to really grasp the idea of sprints and incremental development, they will need to do a number of sprints before stopping to examine themselves; one sprint does not give the full feel for the changes and mindset shift that occurs.  Whether they stop after 4 sprints or after 10 sprints, the team will usually feel one of two ways:  “Scrum seems to be working for us; let’s keep it up, using continuous improvement to get better, and examine again in another few sprints” or “this doesn’t seem to be working; let’s forget Scrum and just do the work”.

When a team feels that Scrum is working for them, they have usually tweaked the framework a bit to allow for their team to feel they are abiding by the Agile Manifesto the best they can to ensure value.  As teams work together, they will tend to work toward continuous improvement and look for ways to work with the customer to ensure their satisfaction.  They will strive to continue to tweak their process to be successful in being Agile.  This type of team is most likely tightknit and feels good in the rhythm they have gotten into—so much so that they may not want to stop to examine, but realize they need to.

The other feeling that comes out is the aforementioned “this doesn’t seem to be working; let’s forget Scrum and just do the work”.  When a team has been doing Scrum for a while and they take stock of where they are, they sometimes conclude that Scrum is more work than they want to expend.  They can see the ceremonies as too much time wasted or that the timebox simply doesn’t fit their needs.  When this happens, they typically chose to abandon the framework and simply ‘work’.  They could just leave Scrum behind and choose a different method to become more Agile, but usually that is not the case because they have come to believe that the road to Agile is the problem; not its implementation of the method or framework.  When the team abandons Scrum, they don’t just abandon the sessions, like sprint planning or retrospectives, they tend to abandon the mindset that being Agile instills.  As they move away from Scrum, they also are likely to shy away from concentrating on the customer and the value they can provide to the customer, which is the core of the ‘Agile way’.  They see the ‘failure of Scrum’ as ‘failure of Agile’ because somewhere along the way, they have equated the two: Scrum = Agile and Agile = Scrum.

As the team ‘does what they want’ and does not follow any Agile methodology, they can easily fall into the trap of ignoring the customer’s wants and needs to the point of missing the mark.  When this happens, we have to examine why the team chose to move toward Agile in the first place:  to deliver what is really needed/wanted and not just what is listed.  If they don’t feel Scrum is working, the team will have a tendency to focus on what they want to do and stuff they find easy. In the end, the product is not what the customer is looking for; there tends to be wasted effort and time.  This wasted effort then results in many other issues with the project/product like not meeting dates, going over budget, risking the cancellation of the project/product, etc.

With all this said, it is not every team that reverts to ‘just working the list’; some simply find other avenues to be Agile other than that of Scrum.  These are the teams that understand that Scrum is maybe not for them, but understand that their attempt to be Agile is not the problem.  These teams usually find a way to move to other methods more suitable, such as Feature Driven Development, Extreme Programming, or even Kanban.

It’s important to remember that the point is to take time and examine what it is that is working, or not working, overall.  Most teams do this at the retrospective, but that should be focused on the team and the sprint.  There should be a time when teams do a more encompassing retrospective that looks at the process as a whole, which would look at things like release planning and working with other teams in the organization.  It is crucial that they take stock of what is working and what is not so they feel empowered to make changes to be as Agile as they can be!

When speaking with leaders in the mortgage banking industry of late, the chorus always remains the same, “we are heads down on TRID.” Despite the CFPB’s recent announcement regarding leniency on enforcement of this new regulation, industry executives know full well that there is no delay. Only firms who make a “good faith effort” to comply with the new regulation will experience leniency on enforcement. The theme at lenders nationwide therefore remains “stay the course” for hitting the August 1^st deadline.

TRID has been widely recognized as one of the single most impactful regulations to befall the mortgage banking industry in recent memory. The real significance of this regulation goes well beyond the requirement to change an already comprehensive and sophisticated consumer disclosure document. By shifting the burden for the consumer closing document three days prior to close from the title company to the lender, it also forces both the lender and title companies to rethink a hundred year old workflow and business relationship, engaging in a more collaborative partnership. To accomplish this effectively, TRID requires lender reconfiguration of business rules, workflows and processes, which has a direct impact on business strategy, technology requirements and system configurations while making certain audit trails go deeper and wider. Amidst it all, lenders are having to work overtime to protect the customer experience by reengineering the loan closing process and better setting expectations with consumer to ensure a positive customer experience and to avoid multiple reschedulings of loan closings. Ultimately putting added pressure on each lender’s cost to produce, not to mention potentially increasing housing costs for consumers.

With less than 60 days remaining to implementation, lenders continue to break the glass and retrieve their proverbial Mortgage Bankers First Aid Kit in order to swiftly bandage together the disparate impact points of TRID, not only to ensure compliance, but for self-preservation. With almost two years to prepare and most vendor organizations fully focused on developing various document solutions and workflow assistance, it’s unfortunate there has been little offered in the way of a universal “one size fits all solution” that lenders can simply plug in and safely implement to help ensure compliance, workflow efficiency and a winning customer experience. Yet after twenty-seven years in the mortgage banking industry, I remain confident mortgage bankers will once again be resourceful, agile and pliable to ensuring successful adoption of the new TRID regulations to ensure consumer satisfaction. After all, it’s in our DNA. We will do what it takes, even if it means throwing bodies at it (similar to days gone by) or adding new layers of manual processes and procedures or quality control checks. I am convinced most will be ready to meet the industry’s new requirements.  But at a cost.

So the question remains, “What’s next? Where do mortgage bankers focus after August 1st?”.

As with many disruptive changes, focus before the deadline is on complying with the regulation. Afterwards the focus must shift to actually making it work effectively and efficiently. This could mean that lenders need to take a pause, step back and get back to the basics by conducting an end-to-end full-scale process assessment. A business process assessment serves to help ensure lenders are originating loans at the lowest possible cost to produce by looking to remove redundancies, maximize technology configurations, better integrate appropriate vendor solutions and new business rules, or by simply amending a series of processes and procedures in light of new ones.

Veteran mortgage banking executive, A.W. Pickel, President and CEO at Leader One Financial, is very concerned about the impact of TRID regulation on consumers. “My concern is, what happens to customers with a moving van in the driveway and due to circumstances beyond their control they now have to wait three more days to close. Regulations meant to do good may cause further harm. Will this regulation then cause realtors and loan officers to do off balance sheet items?” In regards to how to how to mitigate the risk, Mr. Pickel goes on to say, “The only way to offset this risk is through the adoption of additional procedures. In the end, however, additional procedures can equate to increased cost to produce a loan.”

Pete Lansing, former President of Colorado Mortgage Lenders Association and President of Universal Lending for over thirty-four years, feels TRID really isn’t any different than any other regulation. “Post August 1^st we will be in full force compliance evaluation and review, looking for any holes left over that were not covered before the implementation date. Every organization must keep their eye on regulatory compliance at the same time keeping customer service as its number one objective. The balance between these two objectives has always been the mortgage banker’s concern and goal. I believe these new changes are no more difficult than those previously issued by the regulatory forces.”

Taking it one step further, Gellert Dornay, President & CEO of Axia Home Loans, when speaking of his TRID implementation strategy, put it this way, “Post TRID implementation, lenders should be auditing compliance with the new rule and identifying any areas that require further training or process tweaks. However, if you’re not doing a full-scale operational assessment until after the rule has gone into effect, you’ve missed the boat.”

While the mortgage banking apocalypse is not likely to take place on August 1^st, what is more likely is that lenders are going to need to take time post-TRID implementation to conduct a full-scale audit of their end-to-end origination process in order to lower cost to produce and ensure consumer satisfaction. Based on CC Pace’s experience in conducting business process assessments in the mortgage banking industry, we encourage lenders to keep three key components in mind when conducting their post TRID operational assessments. First, be honest in asking yourself if your recently amended TRID process is actually economically “scalable”―is it scalable enough to support what is anticipated to be a growth market if secondary liquidity truly returns due to a rising interest rate environment? Second, when reviewing the operational assessment, challenge yourself with this question, “Is the right long-term answer to take the temporary bandages off and look at full-scale reconstructive surgery of processes, systems and organizational structures in order to successfully implement long-term, scalable growth strategies?” Lastly, decide on a strategy and move forward. Meaningful operational assessments that end up sitting idle on the shelf collecting dust are generally reflective of an overly conservative approach and commitment to long-term failure. Such efforts are best defined as exercises in futility.

After August 1^st there is no better time to stop, rebuild the origination’s foundation and prepare for the new mode of lending.

I recently visited my mom and sisters.  It’s about a four hour drive to where they live, so I stayed with them the whole weekend.  One morning, as we were all gathered in the kitchen, still dressed in our jammies, drinking coffee and chatting, my mom pointed to the aloe plant in the kitchen window.

Mom – “Look…it hasn’t grown in the last six months.  I don’t know what happened to it, maybe I overwatered it.”

Me – “Have you used it to treat any burns or cuts?”

Sister1 – “Nobody’s had any cuts to treat.”

Mom – “And we don’t cook around here, so no burns either.”  (We all laugh at this, because none of us cook muchJ)

Sister2 – “That must be it then, mom.  You’re not using it and it’s stopped growing.”

Me – “What do you mean?”

Sister2 – “Well, mom put it in the window so it gets light and people can see it, but nobody’s using it.  It can’t compete with plants that provide food or that look pretty.  Its strength is in healing.  It’s not doing what it’s best at, so it just sits there, feeling left out, sad, and useless.”

Now, although my sisters and I have been called smart-alecks and wise-guys a time or two, we’re not generally known to spout profoundness or wisdom, especially that early in the morning.  But my sister’s comment struck a chord for me.

Not that I think plants have feelings or anything, it was just a reminder of how powerful it is to feel appreciated for what we can contribute.  Not what we should do, but what we can do….the former is someone else’s yardstick of “good”; the latter is ours.

Simple, genuine appreciation offered by others builds confidence, gives us a sense of meaning and purpose, and sustains us in stressful times.  That conversation also reminded me of a quote I read not long ago by Ram Dass:

“When you go out into the woods and you look at trees, you see all these different trees.
And some of them are bent,
And some of them are straight,
And some of them are evergreens,
And some of them are whatever.
And you look at the tree and you allow it.
You see why it is the way it is.
You sort of understand that it didn’t get enough light, and so it turned that way.
And you don’t get all emotional about it.
You just allow it. You appreciate the tree.
The minute you get near humans, you lose all that.
And you are constantly saying, “You’re too this, or I’m too this”.
That judging mind comes in.
And so I practice turning people into trees.
Which means appreciating them just the way they are.”

As coaches, our job isn’t to judge what a person has to offer as good or bad.  It isn’t to fix or change them.  Our job is to appreciate them just the way they are, to support them as they learn and grow, encourage them, mirror what is, and help them be the best “them” they can be.

I’d love to hear your thoughts….did these examples speak to you?  What did they say?

In previous installments in this series, I’ve talked about what Product Owners and development team members can do to ensure iteration closure. By iteration closure, I mean that the system is functioning at the end of each iteration, available for the Product Owner to test and offer feedback. It may not have complete feature sets, but what feature sets are present do function and can be tested on the actual system: no “prototypes”, no “mock-ups”, just actual functioning albeit perhaps limited code. I call this approach fully functional but not necessarily fully featured.

In this installment, I’ll take a look at the Scrum Master or Project Manager and see what they can do to ensure full functionality if not full feature sets at the end of each iteration. I’ll start out by repeating the same caveat I gave at the start of the Product Owner installment: I’m a developer, so this is going to be a developer-focused look at how the Scrum Master can assist. There’s a lot more to being a Scrum Master, and a class goes a long way to giving you full insight into the responsibilities of the role.

My personal experience is that the most important thing you as a Scrum Master can do is to watch and listen. You need to see and experience the dynamics of the team.

At Iteration Planning Meetings (IPMs), are Product Owners being intransigent about priorities or functional decomposition? Are developers resisting incremental functional delivery, wanting to complete technical infrastructure tasks first? These are the two most serious obstacles to iteration closure. Be prepared to intervene and discuss why it’s in everyone’s interest to achieve this iteration closure.

At the daily stand-up meetings, ensure that every team member speaks (that includes you!), and that they only answer the three canonical questions:

1. What did I do since the last stand-up?
2. What will I do today?
3. What is in my way?

Don’t allow long-winded discussions, especially technical “solution” discussions. People will tune out.

You’re listening for:

• Someone who always answers (1) and (2) with the same tasks every day and yet says they have no obstacles
• Whatever people say in response to (3)

Your task immediately after the stand-up is to speak with team members who have obstacles and find out what you can do to clear the obstacles. Then address any team members who’re always doing the same task every day and find out why they’re stuck. Are they inexperienced and unwilling to ask for help? Are they not committed to the project mission and need to be redeployed?

Guard against an us-versus-them mentality on teams, where the developers see Product Owners or infrastructure teams as “the enemy” or at least an obstacle, and vice versa. These antagonistic relationships come from lack of trust, and lack of trust comes from lack of results. Again, actual working deliverables at the close of each iteration go a long way to building trust. Look for intransigence on either the developer team or with the Product Owner: both should be willing to speak freely and frankly with each other about how much work can be done in an iteration and what constitutes Minimal Value Product for this iteration. It has to be a negotiation; try to facilitate that negotiation.

Know your team as human beings – after all, that is what they are. Learn to empathize with them. How do individuals behave when they’re happy or when they’re frustrated? What does it take to keep Jim motivated? It’s probably not the same things as Bill or Sally. I’ve heard people advocate the use of Meyers-Briggs Personality Tests or similar to gain this understanding. I disagree. People are more complex than 4 or 5 letters or numbers at one moment in time. I may be an introvert today and an extrovert tomorrow, depending on how my job is going. Spend time with people to really know them, and don’t approach people as test subjects or lab rats. Approach them as human beings, the complex, satisfying, irritating, and ultimately rewarding organisms that we actually are.

Occasionally, when I speak at technical or project management meet-ups, an audience member will ask, “I’m a Scrum Manager and I can’t get the Product Owner to attend the IPM; what should I do?” or, “My CIO comes in and tasks my developer team directly without going through the IPM; how do I handle this?” I try to give them hints, but the answer I always give is, “Agile will only expose your problems; it won’t solve them.” In the end, you have to fall back on your leadership and management skills to effect the kind of change that’s necessary. There’s nothing in Scrum or XP or whatever to help you here. Like any other process or tool, just implementing something won’t make the sun come out. You still have to be a leader and a manager – that’s not going away anytime soon.

Before I close, let me point out one thing I haven’t listed as something a Scrum Master ought to be adept at: administration. I see projects where the Scrum Master thinks their primary role is to maintain the backlog, measure velocity, track completion, make sure people are updating their Jira entries, and so on. I’m not saying this isn’t important – it is. It’s very important. But if you’re doing this stuff to the exclusion of the other stuff I talked about up there, you’re kind of missing the point. Those administrative tasks give you data. You need to act on the data, or what’s the point? Velocity is decreasing. OK…what are you and the team going to do about it? That’s the important part of your role.

When we at CC Pace first started doing Agile XP projects back in 2000-2001, we had a role on each project called a Tracker. This person would be part time on the project and would do all the data collection and presentation tasks. I’d like to see this role return on more Agile projects today, because it makes it clear that that’s not the function of the Scrum Master. Your job is to lead the team to a successful delivery, whatever that takes.

So here we are at the end of my series. If there’s one mantra I want you to take away from this entire series, it’s Keep the system fully functional even if not fully featured. Full functionality – the ability of the system to offer its implemented feature set to the Product Owner for feedback – should always come before full features – the completeness of the features and the infrastructure. Of course, you must implement the complete feature set and the full infrastructure – but evolve towards it. Don’t take an approach that requires that the system be complete to be even minimally useful.

If you’re a Product Owner:

• Understand the value proposition not just of the entire system, but of each of its components and subsets.
• Be prepared to see, use, and test subsets, or subsets of subsets of subsets, of the total feature set. Never say, “Call me only when the system is complete.” I guarantee this: your phone will never ring.

If you’re a developer:

• Adopt Agile Engineering techniques such as TDD, CI, CD, and so on. Don’t just go through the motions. Become really proficient in them, and understand how they enable everything else in Agile methodologies.
• Use these techniques to embrace change, and understand that good design and good architecture demand encapsulation and abstraction. Keeping the subsystems isolated so that the system is functional even if not complete is not just good for business. It’s good engineering. A car’s engine can (and does) run even before it’s installed into the car. Just don’t expect it to take you to the grocery store.
• Be an active team member. Contribute to the success of the mission. Don’t just take orders.

If you’re a Scrum Master:

• Watch and listen. Develop your sense of empathy so you “plug in” to the team’s dynamics and understand your team.
• Keep the team focused on the mission.
• If you want to sweat the details of metrics and data, fine – but your real job is to act on the data, not to collect it. If you aren’t good at those collection details, delegate them to a tracking role.

I hope you’ve enjoyed this series. Feel free to comment and to connect with me and with CC Pace through LinkedIn. Please let me hear how you’ve managed when you were on a supposedly Agile project and realized that the sound of rushing water you heard was the project turning into a waterfall.

Each year, the notable Scrum Alliance hosts a Scrum Gathering in an energetic city somewhere in the US.  This year, 2015, the Scrum Gathering was held in Phoenix, AZ at the Talking Stick Resort.  During the 3-day conference at the beginning of May, there were many speakers who took the stage in an effort to share knowledge and experience with those of us who attended the conference.

The week started off with a keynote by Mike Cohn.  The basic theme of his keynote was “#ICouldBeWrong”.  During his “Let Go of Knowing: How Holding onto Views May be Holding You Back” presentation, he spoke of how we as Agilists have long thought certain things were either good practice, part of Scrum, or a belief we have held onto for some time.  He talked about how we may have some beliefs which we consider to be known to us as definitive things that are without question.  We also have other beliefs that are just that—beliefs, or things we have heard, seen or thought and hold onto.  We, as Agilists, need to be open-minded enough to realize there is a difference between these two types of beliefs and that some of the things we believe, even those of the ‘known type’, can be questioned and possibly even refuted.  Mike Cohn used an example where, for a long time, he believed that a team needed to be defined and fixed then, after working with a few teams that weren’t, he managed to change his belief to one that said that teams can be more dynamic and change periodically.  The main thing I took away from this session was that some of the things I think I’m doing that are ‘right’ could actually be the ‘wrong’ thing to do; I need to look at each situation with an open mind and made decisions or recommendations based on those situations.

After the opening keynote, I moved on to the session for which I was the speaker: “Everybody Out of the Pool – Agile Teams and Dedication”.  In this session, which was attended by a number of people, I talked about moving from the concept that project teams are built out of resource pools to the Agile mentality that everyone is a person and they all bring something different to the team.

The remaining portion of Monday was spent in various sessions of 45 or 90 mins each.  My most notable on Monday was a session on coaching conversations.  This was a workshop that was led by Martin Alaimo that centered on the Coaching Canvas.  This workshop gave me great insight into better ways to help clients understand themselves by asking the right questions to learn more about their: 1) goals, 2) impediments, 3) facilitators, 4) action plan.  By using the ‘coaching questions’, from the question bank on the site, you are able to better understand exactly what the needs and wants of your client are and how to help them achieve the goals.

Tuesday morning started out with a series of PechaKucha presentations.  There were 10 in all, with a wide range of topics.  I enjoyed this very much as it was just enough to keep my attention; there was not too much detail.  A couple of the notable topics for me were “Getting Your Team from Good to Great”, “People over Process”, and “So You Want to be a Scrum Trainer”.  Each of these presentations caused me to learn things I didn’t know before, or helped to strengthen my understanding of the topic.  One of the presentations that hit the trainer nerve was the “So You Want to be a Scrum Trainer”.  It really pointed out that we are not just ‘lecturers’ but those of us that do Scrum training must really understand our audience and what they need; but more importantly, we need to understand what they bring to the conversation.

Tuesday afternoon was much like Monday in that it consisted of various sessions of 45 or 90 mins each.  The most notable for me on Tuesday was a session led by Bob Galen where we discussed things that were said by coaches, either those in the room or others, that were anything but encouraging to teams.  After hearing how some coaches may say things like “You do it because I said so and I’m the coach” or “I’m the coach, so you know I’m right”, it got me to thinking about the things I say.  While I would never say these types of things, it provided insight for me to think twice about things I would say before saying them and also to help others from making the same kind of mistakes.

The last thing on Tuesday was a session of Ignite Talks.  Beginning on Monday morning, anyone with any particular topic they wish to present posted those topics and the attendees of the conference voted for the topics they wanted to learn more about.  The Ignite Talks on Tuesday consisted of 10 topics for 10 mins each of those selected by attendees.  There were a number of topics that ranged from Kanban to keeping teams engaged.  While there was no one topic that stood out for me, all of these topics were fun to listen to and contained great information.

On Wednesday morning, while most of the attendees were in Open Space, I attended a workshop on becoming a CST (Certified Scrum Trainer).  The workshop was facilitated by 3 members of the CST TAC (Trainer Approval Committee) that are responsible for interviewing candidates for the CST designation.  During the workshop, those of us in attendance were informed about how the process works, what was expected of us, and were given a chance to ask questions of the TAC members.  During this session, many questions were answered from various attendees.  At the end of the workshop, I walked away with a better understanding of the process and how it would apply to me.

During Wednesday afternoon, there was a closing keynote by Jim McCarthy where he discussed the value of freedom in our “software culture” and how we have obligations to push movements forward so that we can design our culture to meet the needs of the many.

Overall, the Scrum Gathering Phoenix 2015 was a great opportunity to catch up with some old contacts and meet some new ones.  I managed to learn a lot and gain insight into myself and my beliefs as an Agilist.

Looking forward to the next Scrum Gathering!!!

Have you found yourself in this dilemma?  You have just accepted a new job and have been there for 6 months and you are feeling, let’s say, unsure of your decision…..But you are concerned that if you leave, your resume will be perceived as a “job hopper”.  What do you do?  I think many of us at some time or another in our career have been faced with this decision.  I came across this article that discusses the pros and cons of job hopping and thought it provided a good narrative for both sides of this dilemma.  Enjoy and if you are in this situation, I hope it helps you work thru the situation.

https://www.themuse.com/advice/heres-the-truth-about-how-jobhopping-affects-your-career

Do you often feel tensed thinking of tasks started and not completed?  Do you find interruptions frustrating and wish they go away so you can complete tasks started a while back?

If you do, you are not alone and you are likely to experience the Zeigarnik Effect, named after Bluma Zeigarnick, a Lithuanian-born psychologist. In the late 20s, she noticed that waiters seemed to remember complex orders in progress, but forgot all about them when completed. She conducted further studies in which people were required to complete puzzles while being randomly interrupted. It turns out study subjects remembered the interrupted tasks 90% better than the completed tasks and associated interruptions with feelings of frustration. And during the last 80 years, it has repeatedly been demonstrated that people experience unpleasant thoughts about an objective that was once pursued and left incomplete (Baumeister & Bushman, 2008, pg. 122).

Whether it’s something we want to finish or not, it’s our mind’s sometimes incomprehensible but overwhelming desire to finish what we’ve started. Our memory signals the conscious mind, which may be focused on new goals, that a previous activity was left incomplete. It seems to be human nature to finish what we start and, if it is not finished, we experience a state of tension which manifests itself in improved memory for the uncompleted task. As uncompleted tasks accumulate, our level of anxiety will increase and it becomes difficult to pursue any single objective with uninterrupted concentration.

Unfinished tasks tend to constantly interrupt our thoughts, a sort of auto-pilot system reminding us of what needs to be completed. The cognitive effort that comes with these intrusive thoughts of the unfinished task is terminated only once the person returns to complete the task.

Interrupting our efforts to finish a task before it’s complete also seems to interfere with our ability to accurately estimate our productivity, lengthening our estimate of how much time we’ve spent and how much longer it will take us to finish, according to a 1992 study by Greist-Bousquet & Schiffman.

This automatic system that signals our conscious mind that we have unfinished business, provides evidence of a neurological basis for the teachings of Peter Drucker, Jim Collins, Stephen Covey,  and others on the crucial importance of choosing what not to do. Peter Drucker emphasized the importance of using resources on the 10% of things that make 90% of the difference. He described leadership as doing the right things — versus management, doing things right. Likewise Jim Collins describes his “Stop Doing List” as the cornerstone of how he allocates his most valuable resource: time. Stephen Covey espoused effectiveness more than efficiency; getting the right things done at the expense of getting lots of things done.

Our capacity for work and our capacity for attention are limited and are governed by physical laws. Kanban Systems leverage the Zeigarnik effect and help individuals and organizations stay focused on what is important, reduce stress, and improve predictability, morale and productivity. I will show you how in my next blog.

Are you noticing the Zeigarnick effect around you? Please leave a comment below.

_____________

References

Zeigarnik, B.V. (1927). Über das Behalten von erledigten und unerledigten Handlungen (The Retention of Completed and Uncompleted Activities), Psychologische Forschung, 9, 1-85

Baumeister, R.F., & Bushman, B.J., (2008). Social Psychology and Human Nature. United States: Thompson Wadsworth.

Greist-Bousquet, S., Schiffman, N. (1992). The effect of Task interruption and closure on perceived duration. Bulletin of the Psychonomic Society, 30(1), 9-11

In Part 1 of this blog series, I presented a high-level summary of the many different opportunities that Business Analysts (BA) can pursue in an Agile BA role, often resulting in new and exciting experiences. I also highlighted some of the differences between today’s “Agile BA” and the traditional “Waterfall BA”. Finally, I presented an interesting metaphor for today’s Agile BA, one of a Major League Baseball “utility player” (in this case, Jose Oquendo – a player who accomplished the rare feat of playing at every position during his 12-year MLB career.)

Part 2 of this blog entry focuses on the five key functional areas (aka “opportunities”) where I feel Agile BA’s can contribute or take outright ownership of a certain project task or responsibility. A key point to remember is that in order for these opportunities to present themselves, circumstances need to exist which ultimately depend on the dynamics of a project and the makeup of the particular team. Surely we don’t want to step on any toes or introduce team conflict. But if the opportunity is presented and a need has clearly been established, take the bull by the horns and run with these five opportunities:

• Project Management
• Product Management (aka the Product Backlog)
• Testing
• Documentation
• Collaboration (with Project Stakeholders and Team Members)

PROJECT MANAGEMENT – WORK WITH (OR AS) THE SCRUMMASTER

On today’s project teams, Agile BA’s are usually best-suited to provide project management/ScrumMaster support whenever the need arises. And let’s be real – with PM’s and ScrumMasters constantly being pulled in several different directions, the Agile BA can tackle a numerous amount of responsibilities associated with this role.

In all likelihood, Agile BA’s have the experience necessary to handle many of the day-to-day responsibilities of a PM or ScrumMaster. The Agile BA can facilitate any of the recurring “events” as needed – the daily scrum (or “standup”), sprint planning, sprint review and sprint retrospective.

In many cases, the Agile BA is as close to (or even sometimes more engaged) with the project’s product backlog than the actual PM. This knowledge of the past, current and future state of the product backlog enables the Agile BA to assist with several project-related artifacts – for example, sprint and release burn-up/burn-down charts.

Successfully leading and delivering on many of these crucial project events and tasks not only contributes to the success of the team, but it also provides valuable on-the-job training. For Agile BA’s who want to eventually move into a PM or ScrumMaster role, this experience is invaluable.

THE “PROXY PRODUCT OWNER” – TODAY’S “PRODUCT OWNER” REALITY

Lately, it seems that a fully-engaged Product Owner is more of a luxury than a norm on today’s Agile projects. Agile BA’s can benefit from the potential subject-matter knowledge gained and added exposure by bridging this gap and acting as a “Proxy Product Owner”. In cases where a truly-dedicated Product Owner is not a reality, no one is better suited to step into this role than the Agile BA.

BA’s usually develop a solid rapport with the customer and can act as a liaison between the customer and the project team whenever needed. And as stated earlier, the Agile BA probably has the most experience working with the project’s user stories and backlog. On fast-moving development projects, many decisions are needed real-time, and waiting for answers from an absent Product Owner usually hinders the team’s progress.

TESTING – AFTERALL, WHO KNOWS THE STORY BETTER THAN THE BA?

Many Agile teams have already moved to this model, but for teams which have not, here is another opportunity. As previously mentioned, BA’s handing their work over to testers ‘waterfall-style’ is an outdated and inefficient practice. I have seen that 2-3 fully engaged Agile BA’s can efficiently handle the workload of 2-3 full-time BA’s and 2-3 full-time testers. Instead of separating requirements and functional testing tasks for a particular piece of functionality (e.g. user story), Agile BA’s focus on the user story as a whole – from origination (story creation) through implementation (fully-tested, potentially shippable product.) This is not to say that other methods of specialized testing aren’t needed, but in many cases, the best person to drive a user story to “done” is the Agile BA.

Automated testing has also become an invaluable practice on software development projects and provides yet another opportunity for Agile BA’s to contribute in the testing arena. With working knowledge of the current state of the application and product backlog, Agile BA’s have the capability to define and develop a project’s ongoing automated testing suite. Depending on the testing tools employed by the team, BA’s can “pair” with a technical resource (e.g. java developer). In this scenario, the developer handles the technical components of the automated testing suite while the BA designs, builds and manages the suite from a functional perspective.

COLLABORATION – BEFORE YOU KNOW IT, YOU’RE THE PROJECT’S “GO-TO” PERSON

I have included “collaboration” as an opportunity for Agile BA’s because collaboration, indeed, leads to opportunities. In my previous Waterfall experiences, BA’s didn’t collaborate much. In today’s Agile world, the Agile BA can really become a project’s “go-to” person. The collaboration piece also closely ties in with the previously mentioned PM/ScrumMaster and Product Owner opportunities.

For example, facilitating a sprint review or presenting a product demo provides invaluable experience and exposure. Sprint review meetings often include executives and/or stakeholders whom otherwise do not participate at all towards the project (basically, you see them once every two weeks). Leading these sessions provides direct communication with the “customer”, providing valuable feedback which can be relayed back to the team. Since entire project teams rarely attend these informational sessions, the team will start looking to you to provide the important feedback that we all value working on Agile projects. Personally, I have always looked forward to returning to the team room and have always appreciated team members asking, “so, how did it go!?”, after each sprint demo. At the same time, I am always glad to be able to provide that feedback to the team which we can use for future success.

DOCUMENTATION – CHANGE DOCUMENTATION FROM A TEDIUS TASK TO A VALUABLE COMMODITY

Even in today’s Agile world, most software development projects require some essential “dirty work”. The BA role has certainly evolved, but we should not completely abandon our roots. While we’ve all heard repeatedly (sometimes to our detriment) that the Agile Manifesto preaches valuing working software over comprehensive documentation, certain documentation can be critical to the success of projects.

I have seen that, if applied effectively, this basic Agile tenet not only reduces redundant documentation, but it helps teams focus on where documentation actually adds value to a project. Instead of documenting a requirement or process as part of an extensive list of deliverables promised six months ago (which will never be read or will become irrelevant), we document exactly what is needed, today. Most likely, information and processes which need to be documented aren’t even known at the outset of the project. Due to the fact that writing is a core skillset possessed by most BA’s, Agile BA’s are well-positioned to accomplish many of the documentation deliverables needed over the duration of a project.

NOW, GET TO WORK!

You’ve just finished reading this blog entry and your new sprint starts next week. It’s not entirely unrealistic that you can begin working in each of the areas mentioned in this blog over the next two weeks (if you haven’t been already). Offer to facilitate your upcoming sprint planning or review session. Ask the PM if you can contribute to the upcoming metrics reports (e.g. sprint/release burndown). If you aren’t already, start testing user stories – start at a high-level, ensuring that all acceptance criteria is met. Take a few hours, dive into and familiarize yourself with the product backlog. Offer to facilitate the sprint review and invite stakeholders who have become disengaged. And finally, document that process flow which has been taking up valuable whiteboard real-estate for the last several weeks (and really needs to be erased)!

Before you know it, you’re pursuing five completely new opportunities in a matter of two weeks. It might be similar to trying out three completely new positions on a baseball diamond. More importantly, you may even finally be able to explain exactly why Jose Oquendo was such a valuable player to have on a Major League Baseball team.

I once read a book, which shall remain nameless, that seemed to have a quota of illustrations per page: an average of one-third of each page covered by an illustration.  It was a horrible read, made all the worse when I realized that the figures were often repeated to illustrate different concepts with only the captions changed.

Happily, although Ron Jeffries’ own illustrations manage to cover perhaps an average of a fifth of each page in his new book, The Nature of Software Development, they actually add value rather than just taking up space.  Take the illustrations that Ron uses to introduce the idea of incremental software delivery.  It’s very easy to see how people envision their final product in terms of the magic they believe it will be.

The very next illustration, though, helps us recast our thinking in terms of incremental delivery and how it helps us start deriving value from the product we’re building and then another illustration shows how we can use the feedback we get from the earlier releases to produce something better than we’d originally imagined.  Most of the time I honestly ignore illustrations and diagrams as useless, but Ron’s illustrations are generally thought provoking and I always found myself stopping to think about how they illuminated the text around them.

The first part of Nature covers “The Circle of Value,” understanding what value is, why we should try to deliver value incrementally and how we can build our product incrementally.  The second part of Nature is entitled simply “Notes and Essays” and provides more detailed thoughts on some of the subjects touched on in the first part.  One of my favorites was “Creating Teams That Thrive” where Ron reminds us that when the Product Champion, the term Ron is now favoring over Product Owner, brings defined solutions to the team they are less likely to feel a sense of responsibility and pride in the result.

Another nice essay was “Whip the Ponies Harder,” where Ron reminds us that trying to pressure a team into delivering faster can have deleterious effects.  But this brings up a point I wanted to make about the book itself rather than what it says: If you’ve followed along with what Ron has been thinking over the years, in the various discussion groups in which he participates, on xprogramming.com/ronjeffries.com or at the various presentations and classes he’s done, there may not be anything new for you in Nature.  Even if you’re in that situation, it’s probably worth getting the book anyway.  There’s always the possibility that there will be new thoughts for you there, and, even if the ideas themselves aren’t new to you, their presentation in Nature can spur (sorry, the horse/unicorn drawings may be doing something to my language) you to think about them more deeply and also give you a new way to explain those ideas to other people.

A final word of warning: Early on Ron says “[Y]our job is to think a lot, while I write very little.”  This reminded of the time when someone told me they’d read XP Explained (the first edition) in a weekend and understood it all.  After fifteen years, I’m still deepening my understanding of XP, mostly through trying to introduce its values to development groups that don’t necessarily understand what, if any, values they hold.  Even though it’s a short book, give yourself time to really think about what is said in Nature, even after you’ve finished reading it.  That’s when the most reward will come.

What Details?
On a recent flight, I was reading about paying attention to detail in creating a dream room for your home. Attention to detail is important whether you are decorating your house, or building software. I work with Product Owners trying to write user stories so often, I instantly thought “I need to write about user story details”.

When teams are getting started with user stories, the inevitable question is where do my detailed requirements go? I think this is especially true when I work with huge organizations in highly regulated industries.

Details are Important
I’ve seen Product Owners (especially those that were formerly BA’s) fill entire user story description areas with details. In Agile practices, that flies in the face of what the user story is meant to convey. User stories are a trigger for a conversation. User stories should convey to the developer what the user wants to do and why. Once we get past the basics of the user story, then and only then, can we add details in the form of Acceptance Criteria and other attachments (wireframes, mock-ups, database excerpts, etc).

Before I go into user stories, I want to say that not all product backlog items (PBI’s) are user stories. PBI’s may be defects, technical stories, or spikes. If you are a feature team working on a web development project, then demand good user stories. However, if you aren’t in development, or the PBI isn’t a user story, then I question whether or not there is value in trying to force folks into the user story format (As a who, I want what, So that why). I do not question, ever, that we must provide detail along with conversation in order for the work to be performed, tested and accepted.

In organizations that have component teams working on ETL (Extract Translate Load) functionality, middle tier software services being written separately from the consuming team, or scrum teams not related to software at all (marketing, sales, audit), Agile still works and stories still make good PBI’s. Just don’t force yourself into the “user story” format if it doesn’t add value.

Check out Mike Cohn’s blog here for more on “back-end” stories http://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems

Sometimes we use the Agile Manifesto as a reason for skimping on what is needed. I fully believe in “Working Software over Comprehensive Documentation”. I am the first to ask, “who is going to read all this”.  However, I also ensure that my teams get everything they need in order to provide quality results. If this means the Product Owner must work harder at getting the stories ready, then that is what they do. It is their job. Organizations need to know what a big job the Product Owner has. Just because we move from a waterfall version of requirements to Agile versions of requirements doesn’t mean the job takes half the time. In fact, it may take longer. Product Owners must break down stories, get details and be present for discussions with the rest of the team during story grooming/refinement sessions, or during development. If a developer wants more details the Product Owner must get them.

Creating User Stories
What does the process look like? To go from the initial creation of the title to a fully ready story can take any number of days. How much time and effort is spent on documenting the story depends on where it is in the stack ranked order of the backlog. I would rather not put all my effort into stories that aren’t coming up in the next 2 – 3 sprints. Even though I have hundreds of titles ready to go for months’ worth of stories.

Let’s take a look at some examples
The following user story could be broken down smaller, for a start though it meets the basic user story criteria telling who, what and why, but not how. It includes acceptance criteria, and if we were in a tool, I would expect to see supporting attachments.

Title: View Order Details
Description:
As an online customer
I want to see a summary of my complete order before I hit enter or submit
So that I feel confident everything is correct
Acceptance Criteria:

• Ability to preview the order is available
• Preview includes shipping address, billing address, item list, shipping costs, tax, total , payment info (see wireframe attached)
• Payment info shows only the last four digits of card used

User stories are a trigger for a conversation. As we have the conversation a lot of questions should be asked… and results of those questions can be noted below the acceptance criteria.

Now let’s look at a technical story for a component team not invited to share in the front-end team’s user stories:

Title: ETL Sales Report – Team GoGo
Description:
Data must be loaded into the sales data warehouse in order to provide metric reports
Acceptance Criteria:

• Data from XYZ database, tables 1, 2, 3 loaded into warehouse ABC table XXX
  (see attached schemas)
• Stored procedures scheduled to run nightly to load data
• Data transformations run without error
• On error message “….” Sent to “….”

Here is a non-IT story:
Title: 2015 Security Audit – User Access Process System X
Description:
Audit Onboarding process with HR to ensure User Access requests follow approved processes
Acceptance Criteria:

• Audit covers 80% of all request in last 12 months
• Manager’s interviewed and results documented (name, position, date)
• Document audit results following Procedure 123
• Auditor should not be able to request User Access without following the process

So where are the details?
In the Acceptance Criteria and associated documents! If something is missing, get it there before accepting the story into a sprint. If the story looks too big, break it into smaller pieces. Ensure you cover happy path and not so happy path options. Plaster your cube with domain models, object models, etc.

If you’ve been following this series of blog posts about why so many Agile projects seem to deteriorate into waterfall, you know that I believe failure to completely close iterations (or sprints) is a major reason why. If tasks continually spill over from one iteration into the next, the system is never stable enough to demo, and without demos, the feedback loop between the developer team and the Product Owner is broken. Without a rapid feedback loop, Agile doesn’t exist. The project is just a waterfall project with weekly or biweekly status meetings.

What can developer teams do to ensure that iterations close with functioning software that allows the feedback loop to run smoothly?
The most important thing you as a developer can do is to embrace change, as the motto of the Extreme Programming (XP) movement says. Don’t accept change. Don’t tolerate change. Embrace it. Understand that change is the very basis of the evolutionary and incremental approach to software development that is at the heart of Agile methodologies.

What does this mean?
Well, consider that most useful business functionality in an application takes a long time to develop. A single complete use case may take a month or more. And as you consider all the use cases in the system, you begin to see patterns emerging. Perhaps use case 1 requires a way to validate and persist complex incoming data to a database. Use case 20 requires a way to report invalid data to a compliance authority. Use case 35 requires you to deal with the response from the compliance authority. So you begin to think about how you can avoid having to rework what you do for use case 1 to incorporate the later use cases.

This is the road to perdition.

If you want all these use cases to “come together” all at once into a grand spectacle of software delivery, you’ll find it increasingly difficult to show progress along the way. There are too many interlocking pieces that all need to work in order for the whole thing to work. This is how work spills over from one iteration to the next – because the chunks of work you’re taking on are too big.

Instead, embrace change.

Know that some of what you do in use case 1 will likely be reworked for use case 20. This is a good thing, not a bad thing – because it allows you to chunk up your work into smaller pieces that are functional but with limited feature sets.

You may ask: but doesn’t the cost of the rework add up and inflate the project cost?
Yes, a little, but if you diligently use Agile engineering techniques like Test Driven Development (TDD), Continuous Integration (CI), and so on, the cost of change will be greatly reduced, and ultimately the cost will be less than the cost of eliminating the feedback loop. Think of it this way: if you incrementally develop and constantly demo use case 1, the Product Owner may discover that use case 20 needs modification, and that use case 35 goes away. Now you’ve actually reduced cost by using an evolutionary approach. Eliminating the short feedback loop is one of the most expensive things you can do on a software delivery project.

As a member of a developer team, take the iteration planning meetings (IPMs) very seriously. Your focus should be on working with the Product Owner to break down use cases into user stories and tasks that you and your team can complete in an iteration. Keep repeating to yourself: fully functional but not necessarily fully featured. Accept that the feature set is going to grow and evolve, but always keep the system functional so that whatever limited feature set is implemented can be demoed and incorporated into the feedback loop.

For example…
So, let’s take the example of use case 1 above: Validate and persist complex incoming data into our database. Will this fit into a 2-week iteration? Most probably not. So start small. Let’s get some valid data into the database. This needs a couple of tables and some data persistence objects. Will that fit into 2 weeks? Yes, probably, with some time left over. OK, so let’s use the time left over to do 5 of the 120 total validations we will have to do. Decouple the validation from the persistence, because that makes it easier to do each piece – but it’s better software design anyway. How do we report the validation errors with no UI yet? How about writing them to a file? Sure, you’ll end up throwing away the file-writing code, but once again, you’re practicing better software design. You’ve separated performing the validations from reporting the validations.  And you can immediately start demoing your validations to the Product Owner.

(Hint: don’t simply write directly from the validators to a file. Design a validation reporting interface. Implement the interface first as a file, and later as whatever it actually needs to be. Use mock testing frameworks to test-drive the design. This decoupling and abstraction is good design whether you’re using Agile or not.)

Later, you will hook up the validations to the persistence. Then you will deal with how to handle invalid data. Then you will deal with showing validation errors via a UI. All the while, you have full functionality but not necessarily full feature sets. Each piece you develop is small, well-tested, and isolated. You then begin to interconnect them (don’t forget integration testing!) to deliver full feature sets.

[My colleague Robert Pantall wrote a blog post on how he used this technique of accepting controlled rework and incremental discovery to rewire his living room. It’s a fun read.]

Fully Functional, Not Necessarily Fully Featured
Keep in mind that you don’t get to unilaterally decide how the use cases get broken down into small chunks of functionality. You work with the Product Owner to do this, so that each small piece serves some business purpose. It’s a back and forth negotiation between you and the Product Owner.

Everything you do in an IPM should support this goal of evolutionary development that fits into the iteration. Be prepared to estimate quickly so you know whether work will fit. Don’t be afraid to say that work won’t fit and needs to be even more finely chunked down. Speak up. Have a dialog. Work with the product team. Keep the feedback loop running continuously.

After the IPM, when you’re working on the stories or tasks, you may run into unexpected trouble that lengthens the story completion time. Surface this immediately to the product team. You may need to break work down even more. That’s fine. Keep reminding yourself: fully functional, not necessarily fully featured.

I do want to emphasize something at this point. An evolutionary and incremental approach to software development is not a license to hack and slash. Saying you’re using incremental development does not give you an excuse to abandon architectural vision, best practices for design, continuous code improvement by refactoring, or coding standards. You must still design a system for its intended lifetime, following enterprise architecture best practices. Adopting incremental development only lets you make some short-term compromises for the benefit of keeping the software continuously functional. As the software evolves, it must evolve towards your architectural vision and continue to maintain its design and code integrity. As I showed above in the example, if you do this correctly, you’ll mostly be writing throw-away implementations to well-designed, long-term interfaces, and later building permanent production-ready implementations of the same interfaces.

I hope I’ve shown you that change is your friend if you truly adopt incremental delivery. It isn’t something to be feared or managed or avoided. Instead, it’s what makes it possible to develop complex business functionality while at the same time allowing the Product Owner to touch and use the software and to offer continuous feedback. Properly managed through correct Agile engineering techniques, the cost of the required rework fades into insignificance compared to the cost savings of the continuous feedback loop.

Don’t fear change. Embrace it.

Next episode, I’ll focus on what the Scrum Master or Project Manager can do to keep Agile projects from descending into waterfall.

CC Pace employees took a break from their busy schedules for a Cinco de Mayo fiesta! This “holiday” is not Mexican Independence Day as most Americans think.  Cinco de Mayo is the celebration of the Mexican victory over the French at the Battle of Puebla on May 5, 1862. Mexican Independence Day is actually September 16th.

It just wouldn’t be Cinco de Mayo without Margaritas and luckily our Staffing Director had a spare Margarita machine we were able to use.  The fiesta included authentic Mexican goodies brought in by our staff, including homemade Salsa Verde and Tres Leches Cake!

The event also incorporated some friendly competition during a Wii bowling challenge.  The winner will remain nameless, but their victory may be short lived as there is talk of a rematch in the near future.

In January, I moved from Texas to North Carolina.  When I was in Texas, I flew to client sites around the country. But the last few months I’ve been spending more time at clients on the east coast, and have been driving more often.

Now, my brain considers flying an opportunity to catch up on sleep.  Driving on the other hand, is an opportunity to tiptoe-through-the-tulips, or anyplace else it seems.  No map, no rhyme, no particular reason, even…..just random thoughts, reflections, conversions, explorations, and discoveries.

And if the day is sunny and bright, the traffic light, the scenery beautiful, and the music inspiring, I’m filled with the same freshness, optimism and excitement I felt as a kid on a road-trip.  Yet at the same time, quieter, easier, more comfortable being with myself.  I thought I’d periodically share a few of my observations from these road-trips.  Not because they’re brilliant, or deeply philosophical, or earth shattering or anything, but because sometimes random thoughts are all I have.

Last week as I was driving back from NOVA (Northern Virginia), this song by Lee Brice came on the radio.  I was singing along (not well, mind you), and it occurred to me (randomly, of course)….if the conversation took an Agile view, what would it say?  So, I took a shot:

Today, outta the blue

Driving along, singing with the tunes

I heard him say, “What would you do,

If you’d never met me.”

I laughed, and said, “I don’t know,

I could make a couple of guesses, though.”

I breathed deep, my thoughts ran free

I said, “Well, Agile, let me see,

I’d do a lot more estimatin’,

I’d probably spend more time project plannin’,

Play the same ol’ schedule game

If I’d have never known your name

I’d still be doing that ol’ waterfall,

I probably never would have heard the call

Of a different way.

Now, I’m just a simple man

Unaware, yet pretty astute

And, I’d be looking for an option like you.”

I could tell that got his attention,

And I said, “Hey, did I also mention,

I wouldn’t trade one single day

For a hundred years the other way.”

Agile smiled and raised his brow,

‘Cause of course, he’s heard it all

I said, “Come on Agile, don’t you see,

If I hadn’t been so lucky, I’d be

Managin’ meetings for team members,

Reportin’ status to senior leaders,

Stockin’ up on ibuprofen,

Plannin’ stage gates every so often.

There’d be a project schedule in the hall,

And not one index card on the wall,

I’d keep candy in my desk drawer,

But I’d be in an office on a different floor.

And honestly, I don’t know what I’d do,

If I’d never met an answer like you.”

Well, that’s my version….how would your version go?

Art Chantker, President of Potomac Forum, LTD and CC Pace cordially invite you to our next exciting Agile in Government Workshop V, May 20 at the Willard Hotel in Washington DC.  Workshop V will have something for everyone, from new adopters just getting started with Agile in their agencies, to seasoned Agile practitioner scouring the landscape for new horizons in Agile disciplines and trends in the Federal government that they can put to practical use now.

Art has led the Potomac Forum in training thousands of government and industry professionals throughout the country on a wide variety of information technology, acquisition, financial, and management subjects of importance to our government.  Over the years, Art has invited CC Pace back again and again to present on the full spectrum of topics around Agile software development and Agile project management along with officials from the Department of Homeland Security, USDA, the VA, Department of Education, NGA, GSA and many other Federal agencies.

On May 20^th we will be conducting our next Agile workshop at the Willard Hotel for the 2015 Potomac Forum series.  The focus will be on Agile and Lean best practices, including Scrum, Kanban and scaling Agile for larger projects and programs.  In addition to the seasoned Agile trainers from CC Pace, our confirmed government speakers include Karen Ritchey, Assistant Director Applied Research and Methods
U.S. Government Accountability Office; Bill Pratt, Office of the CIO, Policy & Planning-SELC/Agile IT, Department of Homeland Security; and our keynote speaker Greg Godbout, CTO of EPA, and co-founder and former Executive Director of 18F, the government’s new center for inter-agency Agile services.

There is a tentative agenda already posted on the Potomac Forum website, pending some agenda changes once other invited officials are confirmed.  If your agency is starting down the path of agility, or you want to bring your adoption efforts up to the next level you should attend this workshop.  We look forward to seeing you on the 20^th.

http://www.potomacforum.org/content/new-date-agile-development-government-training-workshop-v-implementing-and-managing-agile

Teams that are using the Scrum framework to become more Agile usually use velocity as a metric to help them understand how much value can be accomplished in a given sprint—which also gives a good idea of what value the release can hold.  This metric is something each team strives to improve through continuous improvement of their processes and teamwork.  However, the meaning is not altogether taken at face value…

When you think of velocity, what do you think of?  Do you think about the higher the number, the better or equating velocity to the amount of work the team does?  Does your team strive for high velocity?  If so, why?

Teams use velocity for a multitude of reasons; few of which are actually valid.  These valid reasons usually include improving themselves, using it for planning purposes, and sometimes for proving their abilities as a team.

When you remove the valid reasons, there are many other reasons that velocity is used as a metric, and some of them are not so ‘friendly’ to the team, or to being Agile.  A few I have heard or seen include: measuring the team’s pace, using it to force the team to do more than they are really capable of, using it to mix up teams, having it prove that “Agile fails”, apply it as a way to show risk to the project, and, maybe the worst, using velocity as a way to push the team into a ‘death march’ to completion.  I have seen many teams that end up failing because someone, who may not understand the purpose of velocity, pushes the team over the edge and they “storm” over how they should be working.

When we look at velocity, it is indeed meant to measure the throughput of the team in a given sprint—how much the team completed during the sprint.  The original intent of this measurement is to assist in planning the amount of work that the team can accomplish in a sprint, and therefore how much scope can be accomplished in a given number of sprints, or a release.

By looking at the definition and the original intent, you can clearly see how the intent can be morphed or twisted into some other purposes, like those listed above as the ‘not-so-friendly’.  This is not unlike many large companies in their infancy of an Agile transformation—they are not sure what to do with this new metric and so they use it as they see fit, even if it’s not the purpose.  When this happens, it tends to cause riffs inside the teams and across teams.  The worst scenario is when organizations that do not have the proper training or coaching in Agile attempt to ‘read between the lines’ and begin to infer things about the team, such as how hard they are working or even whether they are working at all.

It is important to understand that numbers do not tell the whole story, but merely start the conversation.  The conversation is worthwhile so that the team, and the organization, can better recognize what is happening with the team and how they are attempting to become more Agile.

Another murky side to how some teams’ velocities are used is to compare team to team—as if a higher velocity by one team over another means there is a better team.  The idea that teams can be compared by simply comparing velocities is a bit absurd—there are so many reasons that one team’s velocity may be higher than another’s, which is more evidence that numbers do not tell the whole story.  When velocities are used to compare team against team, you find that it creates friction between teams.  As the relationship between teams is strained, the value that the teams produce begins to dwindle or be of less quality.

Velocity is one thing that a team should never compromise; their velocity is what helps to keep them on a more sustainable pace and helps prevent them from getting burned out.  The biggest thing that velocity gives a team is a way to keep from committing to more than they can realistically deliver.

After reading this, would you change how you measure your team’s, or teams’, velocity?  Does it change how you interact with other teams?  Feel free to comment on how you use, will change, or see velocity.

As I write this blog entry, I’m hoping that the curiosity (or confusion) of the title captures an audience. Readers will ask themselves, “Who in the heck is Jose Oquendo? I’ve never seen his name among the likes of the Agile pioneers. Has he written a book on Agile or Scrum? Maybe I saw his name on one of the Agile blogs or discussion threads that I frequent?”

In fact, you won’t find Oquendo’s name in any of those places. In the spirit of baseball season (and warmer days ahead!), Jose Oquendo was actually a Major League Baseball player in the 1980’s, playing most of his career with the St. Louis Cardinals.

Perhaps curiosity has gotten the better of you yet again, and you look up Oquendo’s statistics. You’ll discover that Oquendo wasn’t a great hitter, statistically-speaking. His career .256 batting average and 14 homeruns over a 12 year MLB career is hardly astonishing.

People who followed Major League Baseball in the 1980’s, however, would most likely recognize Oquendo’s name, and more specifically, the feat which made him unique as a player. Oquendo has done something that only a handful of players have ever done in the long history of Major League Baseball – he’s played EVERY POSITION on the baseball diamond (all nine positions in total).

Oquendo was an average defensive player and his value obviously wasn’t driven from his aforementioned offensive statistics. He was, however, one of the most valuable players on those successful Cardinal teams of the 80’s, as the unique quality he brought to his team was derived from a term referred to in baseball lingo as “The Utility Player”. (Interestingly enough, Oquendo’s nickname during his career was “Secret Weapon”.)

Over the course of a 162-game baseball season, players get tired, injured and need days off. Trades are executed, changing the dynamic of a team with one phone call. Further complicating matters, baseball teams are limited to a set number of roster spots. Due to these realities and constraints of a grueling baseball season, every team needs a player like Oquendo who can step up and fill in when opportunities and challenges present themselves. And that is precisely why Oquendo was able to remain in the big leagues for an amazing 12 years, despite the glaring deficiency in his previously noted statistics.

Oquendo’s unique accomplishment leads us directly into the topic of the Agile Business Analyst (BA), as today’s Agile BA is your team’s “Utility Player”. Today’s Agile BA is your team’s Jose Oquendo.

A LITTLE HISTORY – THE “WATERFALL BUSINESS ANALYST”

Before we get into the opportunities afforded to BA’s in today’s Agile world, first, a little walk down memory lane. Historically (and generally) speaking – as these are only my personal observations and experiences – a Business Analyst on a Waterfall project wrote requirements. Maybe they also wrote test cases to be “handed off” and used later. In many cases, requirements were written and reviewed anywhere from six to nine months before documented functionality was even implemented. As we know, especially in today’s world, a lot can change in six months.

I can remember personally writing requirements for a project in this “Waterfall BA” role. After moving onto another project entirely, I was told several months down the road, “’Project ABC’ was implemented this past weekend – nice work.” Even then, it amazed me that many times I never even had the opportunity to see the results of my work. Usually, I was already working on an entirely new project, or more specifically, another completely new set of requirements.

From a communications perspective, BA’s collaborated up-front mostly with potential users or sellers of the software in order to define requirements. Collaboration with developers was less common and usually limited to a specific timeframe. I actually worked on a project where a Development Manager once informed our team during a stressful phase of a project, “please do not disturb the developers over the next several weeks unless absolutely necessary.” (So much for collaboration…) In retrospective, it’s amazing to me that this directive seemed entirely normal to me at the time.

Communication with testers seemed even rarer – by the very definition, on a Waterfall project, I’ve already passed my knowledge on to the testers – it’s now their responsibility. I’m more or less out of the loop. By the time the specific requirements are being tested, I’m already off onto an entirely new project.

In my personal opinion the monotony of the BA role on a Waterfall project was sometimes unbearable. Month-long requirements cycles, workdays with little or no variation, and some days with little or no collaboration with other team members outside of standard team meetings became a day to day, week to week, month to month grind, with no end in sight.

AND NOW INTRODUCING… THE “AGILE BUSINESS ANALYST”

Fast-forward several years (and several Agile project experiences) and I have found that the role of today’s Agile Business Analyst has been significantly enhanced on teams practicing Agile methodologies and more specifically, Scrum. Simply as a result of team set-up, structure, responsibilities – and most importantly, opportunities – I feel that Agile teams have enhanced the role of the Business Analyst by providing opportunities which were never seemingly available on teams using the traditional Waterfall approach. There are new opportunities for me to bring value to my team and my project as a true “Utility Player”, my team’s Jose Oquendo.

The role of the Agile BA is really what one makes of it. I can remain content with the day to day “traditional” responsibilities and barriers associated with the BA role if I so choose; back to the baseball analogy – I can remain content playing one position. Or, I can pursue all of the opportunities provided to me in this newly-defined role, benefitting from new and exciting experiences as a result; I can play many different positions, each one further contributing to the short and long-term success of the team.

Today, as an Agile BA, I have opportunities – in the form of different roles and responsibilities – which not only enhance my role within the team but also allow me to add significant value to the project. These roles and responsibilities span not only across functional areas of expertise (e.g. Project Management, Testing, etc.) but they also span over the entire lifetime of a software development project (i.e. Project Kickoff to Implementation). In this sense, Agile BA’s are not only more valuable to their respective teams, they are more valuable AND for a longer period of time – basically, the entire lifespan of a project. I have seen specifically that Agile BA’s can greatly enhance their impact on project teams and the quality of their projects in the following five areas:

• Project Management
• Product Management (aka the Product Backlog)
• Testing
• Documentation
• Collaboration (with Project Stakeholders and Team Members)

We’ll elaborate – in a follow-up blog entry – specifically how Agile BA’s can enhance their role and add value to a project by directly contributing to the five functional areas listed above.

I get this question a lot. And I ask back “What business problems are you trying to solve?” Each method has great potential when applied within the right context. If you are already using one of them, it doesn’t mean that you can’t use practices from the other. You should adopt any practice that enhances your current toolset for solving business challenges.

Here is a good article that takes a pragmatic approach on how each one of the methods can be used based on what is best for your customers: What is Best, Scrum or Kanban? – http://www.agileconnection.com/article/what-best-scrum-or-kanban

CC Pace provides a variety of Agile services, and we can help you build your toolset as your business needs change. This blog site is a great forum to ask methodology related questions. What do you want to learn more about?

I found Mike Cohn’s posting Don’t Blindly Follow very curious because it seems to contradict what many luminaries of the Agile community have said about starting out by strictly following the rules until you’ve really learned what you’re doing.

In one sense, I do agree with this sentiment of not blindly doing something.  Indeed, when I was younger, I thought it was quite clever of me to say things like “The best practice is not to follow best practices.”  But then I discovered the Dreyfus Model of Skills Acquisition and that made me realize that there’s a more nuanced view.  In a nutshell, the Dreyfus model says that we progress through different stages as we learn skills.  In particular when we start learning something, we do start by following context-free rules (a.k.a., best practices) and progress through situational awareness to “transcend reliance on rules, guidelines, and maxims.”  This is resonates with me since I recognize it as the way I learn things and when I can see it in others when they are serious about something.  (To be fair, there are people that don’t seem to fit into this model, too, but I’m okay with a model that’s useful even if it doesn’t cover every possibility.)  So, I would say that we should start out following the rules blindly until we have learned enough to recognize how to helpfully modify the rules that we’ve been following.

Cohn concludes with another curious statement: “No expert knows more about your company than you do.”  Again, there’s a part of me that wants to agree with this, but then again…  An outsider could well see things that an insider takes for granted and have perspectives that allow them to come to different conclusions from the information that you both share.

I find myself much more in sympathy with Ron Jeffries’ statements in The Increment and Culture: “Rather than change ourselves, and learn the new game, we changed Scrum. We changed it before we ever knew what it was.”  This seems like it would offer a much better opportunity to really learn the basics before we start changing this to suit ourselves.

When our yacht club saw membership dropping and was looking for a change, I called our Chairmen of the Board and suggested… a Kanban board.

Lucky for me, our Chairmen works in software for a well know online travel site. He knew just what I was talking about. After a short discussion, we decided to introduce the ideas of Scrum to the board. At our next Board of Directors (BoD) meeting I turned up, white board and 3 x 5 cards in hand.

Together we introduced the BoD to the idea of using a Scrum board to track our work. We started by brainstorming ideas in two key categories supporting the club’s 2015 goal of Membership retention and growth. Our two categories are membership activities and building improvements. After creating quite a backlog for the club, we discussed priority, and arrived at a commitment to working on a subset of the backlog for the upcoming sprint. Our sprint cycle was easy to determine as there are two meetings a month at the club, providing approximately 2 weeks in between each meeting. Board members signed up for stories listed in the backlog to get us off and running. At our general membership meeting, the visual board with our sprint and “product” backlog were introduced to the club.

Being “Agile” is a way of thinking. Core ideas like transparency, prioritizing, and collaboration can be incorporated into our everyday lives. I often suggest using a visual board for household chores when I’m doing training. No more nagging your partner, or kids. Just keep a board with 3×5 cards or post-its to identify upcoming work. Identify priority, acceptance criteria, and limit your work in progress by identifying a sprint length (one – two weeks work well). This helps to keep from feeling overwhelmed. Everyone is happier knowing what is expected. I’ve tried this at home with good success which is what led me to suggesting this for our club.

In taking these same principles and applying them to our club, we’re able to benefit from being Agile. The club members are our customers. They get visibility and input into the work being done. Members can make suggestions for new work, and volunteer to help. The club’s budget helps identify what can be afforded, and expected ROI helps us prioritize. Our initial work is underway, and I look forward to seeing our long-term projects lead us to sustaining and even growing our membership.

For the past 3 months we’ve had the pleasure of working with a charitable organization called the Ceca Foundation.

Ceca, which is derived from “​celebrating caregivers”, was established in 2013 to celebrate caregiver excellence and “to promote high patient satisfaction by recognizing and rewarding outstanding caregivers”. They do this by providing employees of caregiving facilities with a platform for recognizing and nominating their peers for the Ceca Award – a cash reward given throughout the year. These facilities include rehabilitation centers, hospitals, assisted living centers and similar organizations.

CC Pace partnered with Ceca to build their next generation, customized nomination platform.

This was one of those projects that fills you with pride. First, for the obvious reason – Ceca’s worthwhile mission. Second, the not-so-obvious reason, which was the development process. It was a great example of why I enjoy helping customers build products.

The process

For various reasons, Ceca was under a tight deadline to get the new platform up-and-running for several facilities. The Agile process turned out to be a great fit, as it allowed for frequent customer feedback and weekly deployments to a testable environment. We developed the platform using high-level feature stories, rather than detailed specifications. This allowed the team to concentrate on the desired outcome, rather than getting caught up in the technical details. At times, we had to forgo a software-based solution in favor of a manual process. When you have limited resources and time, you have to make these types of decisions.

In February, after about 3 weeks, the Ceca Foundation launched the new web platform for one facility and then quickly brought on several more. There was immediate gratification for the team as we watched the nominations flood in.

The “feel good” story

What made this project successful and enjoyable at the same time? I’m reminded of the first value in the Agile manifesto – individuals and interactions over processes and tools. Some factors were technical but most were not:

• a motivated and enthusiastic customer (Ceca)
• a set of agreed upon features to provide the Minimum Viable Product
• frequent collaboration with the customer
• a cloud-hosted environment to provide infrastructure on-demand for testing and live versions
• a software-as-a-service model that allowed us to quickly bring on new facilities

For me, it was Agile at its most fundamental: discuss the desired features; provide a cost estimate for those features; negotiate priority with the customer; provide frequent releases of working software.

Check out the Ceca Foundation for more information. You can see a demo of the software under “Technology​“.

Hard to believe we are almost through the first quarter of 2015!  Since CC Pace likes to participate in at least one charitable event a quarter we have decided to give back to our four-legged friends.  Homeward Trails Animal Rescue is a non-profit organization that provides adoption in the Virginia, DC, and Maryland area.  They find homes for dogs and cats that were rescued from high-kill animal shelters or whose owners could no longer care for them.

Meet Branson, he is 6 months old and amazingly sweet, he will roll over on his side and show you his belly at first meeting. He is a young boy who will melt your heart and wants nothing more than to find his forever home. Branson is just one of many adorable animals that Homeward Trails has available for adoption.

The CC Pace team pulled together and we were able to gather various items to help support this organization’s efforts.  There was even talk of a possible adoption.

For more information about Homeward Trails and their mission you can go to http://www.homewardtrails.org/.

A colleague recently reached out for suggestions to help a new client whose teams are having trouble adapting to using story points.

Here are 10 tips to keep in mind when helping teams in their transition:

Change the Language – Are We Estimating Effort or Estimating Size
Story points are intended to reflect relative size.  And while they are loosely correlated to effort (e.g., the bigger something is, the more effort it takes to do it), they are not meant to represent a precise measure of effort.

If your teams are grappling with estimating-in-story-points, try changing your language to sizing-in-story-points.  It’s a subtle difference for those of us familiar with the concepts, but can ease the transition for those new to it.

Create New Language – Stay Away from Numbers
Historically, we think of size in terms of how-long it will take to do it.  Break that strong association by using a non-numeric, relative scale such as t-shirts, dogs, boats, planes, fruits, vegetables, candy, or planets.

Clarify Language – Are We Talking Effort or Duration
Let’s take a simple example…..I have a friend who can drive across country in 3 days by herself.  It takes me a week.  Assuming we’re taking the same route, and driving the same speeds, why is there a difference?  It turns out that my friend can drive 12-13 hours a day with minimal stops.  Whereas I start falling asleep after 2-3 hours and have to stop frequently.  So it takes me longer (duration) to do the same amount of work (effort).

Duration is the time it takes to complete something from start to finish and is stated in “duration-units” such as hours, days, weeks, or months.   Work (effort) is the amount of work required to complete something and is stated in “work-units” such as man-hours or man-days.  Because these both have a “time” component, we often mingle them together inappropriately, causing problems if there’s not a clear, shared understanding.

For instance, when I estimate a task to be 40 hours, what I mean is “it will take me 40 man-hours to do this, if I have the information and decisions I need in a timely manner, if tools are available when I need them, and if I’m not working on anything else”.  What others often hear is “it will take someone a week to do this”.  I’m talking about effort; others are hearing duration.

The teams my colleague observed used the following definition when estimating their stories:
1 SP = 3-4 days
2 SP = 1 week
3 SP = 2 weeks
5 SP = 4 weeks
8 SP = 6 weeks
They are tracking actual hours worked on each story and are expecting that a 2-point story equates to a consistent number of hours.  But their definition is expressed in duration-units rather than work-units, and the actual effort to complete a 2-point story can vary widely depending on whether one person can finish it in a week or it takes 4 people to complete it.

Don’t define story points in duration-units and expect it to correlate to effort.

Skip Estimation, Go Directly to Work
If your teams are thrashing because of estimation, then don’t estimate.  Use commitment based-planning and have them track their story throughput rather than points or hours.  As they become more comfortable with this, stories will begin to creep smaller and smaller naturally.  Check out more about the #NoEstimates movement.

Compare to a Baseline
Have the team select a story that is representative of the type of work they do, assign a size to it, then compare all other stories relative to the baseline.

Practice Often
The more the team does what’s uncomfortable for them, the more practice they get, and the better they will get at it.  Opt for shorter iteration lengths, as this will offer more opportunities to practice.

Value First
If teams are thrashing, there may be too many changes happening at once for them to absorb.  We’re looking for the creativity and speed that comes from being on the edge of chaos, not in the middle of it.

Focus efforts on improving the ability to create vertical slices of value.

Then Flow
Once teams can craft valuable slices, focus on reducing the variability in story sizes rather than thrash about estimating.  Strive for small stories using story-splitting techniques.  Smaller slices are easier to size, easier to finish, make mistakes visible sooner, and allow for quicker feedback.  Smaller stories also improve the flow of work.

As stories become small, uncertainty and dependencies decrease, and effort and duration can be good approximations of each other.  A rule-of-thumb is a story should be small enough to be completed in less than 1/3 the length of your iteration, e.g., no longer than 3-4 days in a 2 week iteration.  Mature teams will often have stories that take around one day, and all their stories are of similar size.

Remember – it’s the Conversation that’s Important
The magic about relative estimation is not in getting to an answer, but in the conversation that leads to shared understanding.

And…don’t Over-Stress the System
No matter what anyone thinks, pressuring a team to accept 800 hours of “planned” work when they only have 500 hours of capacity is not reasonable, and it will never work.  Forget the “if you challenge them, they will rise to the occasion” call to arms.  After a certain point, that’s just a bunch of malarkey.

As my grandma used to say, “You can’t get blood from a turnip”.

As I mentioned in the introductory post in this series, an issue I frequently see with underperforming Agile teams is that work always spills over from one iteration into the next. Nothing ever seems to finish, and the project feels like a waterfall project that’s adopted a few Agile ceremonies. Without completed tasks at iteration planning meetings (IPMs), there’s nothing to demo, and the feedback loop that’s absolutely fundamental to any Agile methodology is interrupted. Rather than actual product feedback, IPMs become status meetings.

In this post, let’s look at how a Product Owner can help ensure that tasks can be completed within an iteration. As a developer myself, I’m focusing on the things that make life easier for the development team. Of course, there’s a lot more to being a good Product Owner, and I encourage you to consider taking a Scrum Product Owner training class (CC Pace offers an excellent one).

First and foremost, be willing to compromise and prioritize. An anti-pattern I observe on some underperforming teams is a Product Owner who’s asked to prioritize stories and replies, “Everything is important. I need everything.” I advise such teams that when you ask for all or nothing, you will never get all; you will always get nothing. So don’t ask for “all or nothing”, which is what a Product Owner is saying when they say everything has a high priority.

As a Product Owner, understand two serious implications of saying that every task has a high priority.

1. You are saying that everything has an equal priority. In other words, to the developer team, saying that everything has a high priority is indistinguishable from saying that everything has medium or indeed low priority. The point of priority isn’t to motivate or scare the developers, it’s to allow them to choose between tasks when time is pressing. You’re basically leaving the choice up to the developer team, which is probably not what you had in mind.
2. You’re really delegating your job to the developer team, and that isn’t fair. You’re the Product Owner for a reason: the ultimate success of the product depends on you, and you need to make some hard choices to ensure success. You know which bits of the system have the most business value. The developers signed on to deliver functionality, not to make decisions about business value. That’s your responsibility, and it’s one of the most important responsibilities on the entire team.

The consequence of “everything has a high priority” is that the developers have no way to break epic stories down into smaller stories that fit within an iteration. Everything ends up as an epic, and the developer team tends to focus on one epic after another, attempting to deliver complete epics before moving on to the next. It’s almost certain that no epic can be completed in one 2-week iteration, and so work keeps on spilling over to the next iteration and the next and the next.

Second, work with the developer team to find out how much of each story can be delivered in an iteration. Keep in mind that “delivered” means that you should be able to observe and participate in a demo of the story at the end of the iteration. Not a “prototype”, but working software that you can observe. Encourage the developers to suggest reduced functionality that would allow the story to fit in an iteration. For example, how about dealing only with “happy path” scenarios – no errors, no exceptions? Deal with those edge cases in a later iteration. At all costs, move towards a scenario where fully functional (that is, actually working) software is favored over fully featured software. Show the team that you’re willing to work with the evolutionary and incremental approach that Agile demands.

Third, be wary of stories that are all about technical infrastructure rather than business value. Sure, the development team very often need to attend to purely technical issues, but ask how each such story adds business value. You are entitled to a response that convinces you of the business need to spend time on the infrastructure stories.

At the end of a successful IPM, you as the Product Owner should have:

• Seen some working software – remember, fully functional but perhaps not fully featured
• Offered the developer team your feedback on what you saw
• Worked with the developer team to have another set of stories, each of which is deliverable within one iteration
• Prioritized those stories into High, Medium, and Low buckets, with the mutual understanding  that nobody will work on a medium story if there are high stories remaining, and nobody will work on low stories if there are medium stories remaining
• A clear understanding of why any technical infrastructure stories are required, and what business problem will be addressed by such stories

Finally, make yourself available for quick decisions during the iteration. No plan survives its first encounter with reality. There will always be questions and problems the developers need to talk to you about. Be available to talk to them, face to face, or with an interactive medium like instant messaging or video chat. Be prepared to make decisions…

Developer: “Sorry, I know we said we could get this story done this iteration, but blahblah happened and…”

You: “OK, how much can you get done?”

Developer: “We would have to leave out the blahblah.”

You: “Fine, go ahead.” (Or, “No, I need that, what else can we defer?”)

Be decisive.

Next post, I’ll talk about what developers should concentrate on to make sure some functionality is delivered in each iteration.

An important part of any system selection process is when the vendor is asked to demonstrate their products. This is a pivotal time, when the dry responses to the RFP become something that is seen and the staff can begin to visualize themselves using the system in their daily work.  Selection Team members walk out of a demonstration with their preconceptions turned into expectations of what the product can or cannot do, and what benefits it may bring to the organization.  These impressions stick with the audience; it is hard to move someone away from what they’ve seen or heard during a demonstration.

I’ve always considered the demonstration, as well as the set-up and coordination activities around this meeting, as where I earn most of my fee for managing a selection process.  It is important not to view this as a one-off meeting, or standalone activity, but to view it as integral to the overall selection process using information already collected and providing output to the next steps, as well as the final decision.

Steps prior to the demonstration including defining and prioritizing the business requirements, creating a potential product list, developing/distributing an RFP and assessing the vendor responses.  That assessment should narrow down the field to those 2-4 vendors that best meet your baseline requirements and are most worthy of being invited in for a demonstration.

Recommended activities to surround the demonstration, include:

Schedule:  I try to group the demonstrations within a 1-2 week time period, without significant time gaps between sessions.  This is rough on the individual calendars of those attending the meetings, but worth it to keep the purpose, critical requirements and comparisons top of mind throughout.

Agenda: Using the most critical requirements identified previously, the agenda is set to walk through all key aspects of the functionality, with a focus on any particular area where the selection committee is particularly concerned.  The agenda is also set up to allow users to manage their time, so they are only present when the demo is covering their functional areas, without tying them up for the full session. Importantly, a well thought out agenda ensures the vendor spends adequate time on all the aspects of the system the team is interested in, with little opportunity to gloss over areas of weakness.

Scorecard:  Any attendee in the demonstration should complete a scorecard for the parts of the demo they participated in.  The scorecards must be completed before the participant exits the room, as their thoughts quickly get mixed between systems, and other priorities occur that take attention and time away from completing the scorecard.  The scorecard is never overly long, but serves to provide a quantitative view of the participant’s impression of specific functionality in the system, and to capture any comments or questions that may be pending at the end of the demo.  To avoid skewing the quantitative results, participants should only score those sections with which they have expertise.  Entries on the scorecard are aligned with the agenda for easy following, and are weighted based on priority for quantitative comparison across products.

Attendees:  I discourage the selection team members from looking at the systems early in the process, before their requirements are known and prioritized, to avoid any preset leanings in one direction or another.  The size of the group varies on the size of the organization, breadth of functionality for the system being selected and amount of time devoted to the selection.  The preference is to keep the participating audience at a manageable size and consistent across all systems being considered.  All audience members should be prepped beforehand, as to how the meeting will run, the agenda and the scorecard.

Facilitation:  The facilitator role is an active one, ensuring the focus remains on the agenda and covers all the topics in the scorecard.  Questions may be tabled, conversations cut short (particularly those that serve a small part of the audience present at that time), and information prompted out of the audience or the vendor.  Another role is that of translator and interpreter.  It always stuns me how we all say the same things in entirely different ways within and across financial sectors.  It is important that the vendor’s presentation is translated into the audience’s terminology whenever possible for maximum appreciation of what is being presented.  It is equally important to also interpret what the vendor says into how the audience members think.  The facilitator’s knowledge of the industry, the available products, implementation, maintenance, etc. are all leveraged to steer the discussion such that the audience will appreciate not only what they are seeing, but what they will need to contribute for configuration and maintenance and whether the system has the flexibility to meet their needs in different ways.  This leads to a more mutually fulfilling discussion between the vendor and the audience, as everyone speaks from the same page.

Post-Meeting Roundtable:  A facilitated session of key audience members should quickly follow each demonstration (to mitigate crossover confusion with what functionality went where or when a particular comment came up).  A review of the scorecards should be completed prior to this session, so disparities can be addressed.  This meeting is the opportunity to discuss the demo, questions raised, and establish a general consensus about where the product stands and that the functionality represents similar things to everyone.  It is not unknown to find a score of 1 and a score of 5 (using a 1-5 range) for the same functionality line item on the scorecards of two different participants.  There is no expectation that everyone will score things the same, rather that scores should be in a similar ballpark.  Large disparities like this one indicate misunderstandings by one or both team members, and those need to be put on the table for clarification as soon as possible, before perceptions are cemented and expectations set in one’s mind that cannot be met.

I know companies who failed to follow one or more of the steps above during their selection process and the result was typically missed expectations and buyer’s regret.  Allowing the vendors free roam for their demonstrations causes confusion when comparing products, as the vendors may approach the discussion from totally disparate functional areas.  Lack of a schedule requires a larger investment of time, as people with only a small area of functionality to observe are sitting in for much longer time periods (or the meeting is stopping and starting, while new people are called in and others leave). Most importantly, what someone hears versus what was intended may be completely different messages that were not caught prior to a final recommendation.  That “results in not getting what you thought you were getting”.

While key to the overall selection process, the demonstration is not the final task in the process.  A quantitative comparison of RFP responses and demo results can be used to further reduce the short list of potential candidates prior to moving into an in-depth due diligence process.  Targeted system demonstrations, or question/answer sessions with the vendor may occur during this period to collect additional information or clarify any points.

Once the due diligence is completed, the qualitative and quantitative results are assessed to identify the final recommendation from the selection process.

On February 25^th and 26^th, I had the pleasure of attending the “Agile in Government” conference put together by AFEI (The Association For Enterprise Information). The theme of this year’s conference was Mutual Adaption – Adapting Agile to acquisition and acquisition to Agile.

While attending the conference, I had the privilege of listening to some great speakers on various topics, including contracting Agile in the government, DevOps use in the government, how cloud computing is the next ‘big’ thing for government agencies, and how EVM plays a role in government projects.

Roger Baker kicked off the event with the keynote talk on day 1 discussing how to ensure the success of Agile projects.  He had 2 very powerful points:  base the solution on solving the mission and not the technology and what he called ‘Success Makers’ for Agile projects.  Mr. Baker pointed out that he is very adamant about keeping program lengths 6 months or less to root the program in deadlines, which helps to keep things moving.  He also discussed that the acceptable rate of success should be more like 80%, instead of the current 16%.  Mr. Baker’s success factors are to ensure prioritization, impose deadlines, force decision making, and involving users in everything; it “takes a village to move things forward” he notes.  My favorite quotable sentence from Mr. Baker was “Agile is not the answer to everything, but waterfall is the answer to nothing.”

There were a number of speakers that touched on how to use contracts in the government for acquisitions; after all, that was the theme of this year’s conference.  Each of the speakers discussed how there are numerous types of contracts that lend themselves to Agile very well.  One that is becoming more and more popular is that of indefinite delivery, indefinite quantity (IDIQ) which allows for changes through task orders.  These speakers concentrated heavily on the FAR[1] which has been shown support Agile acquisitions.

Another topic that was a headliner was that of EVMS, or earned value management system.  EVM is a management tool and not something that is a day-to-day monitoring tool.  EVM helps to track time and budget at a program level.  The one thing that makes the EVM stand out is that it is really about value; as a couple speakers pointed out, you really have as much time as you need but it is about the amount of value that you need to deliver in a set timeframe.  The easiest way to ensure that the value is kept in check, relevant to the time and budget, is to prioritize.  Prioritization is a point that was continually hammered by each speaker, including those that spoke of EVM.

David Linthicum, keynote speaker on day 2, spoke about how cloud computing is the future for the government.  He pointed out how it not only helps to speed things up but also how it is something that really cannot be ignored if government agencies wish to have systems to be more reliable and scalable.  As with a number of other speakers, Mr. Linthicum pointed out that just switching architecture is not the answer to becoming faster, more reliable, and more scalable; there also need to be things such as continuous integration, automated testing, and the ability to spin up environments at the drop of a hat.  All of these concepts lend themselves to points made that it is paramount to adhering to developing on cadence, releasing on demand.  Mr. Linthicum laid out a number of variables that need to be accounted for when moving to cloud computing and noted numerous times that a change of that magnitude takes time.  He hypothesized that if government agencies began planning to move to cloud computing now, and moved forward, they would be there by 2019-2020.  Another point that Mr. Linthicum drove home is that, contrary to what some think, it is not possible to ‘balance out’ the cost with the savings; there will be a cost to moving, but then savings in things like operations and reliability will be seen long term—not immediately.

Another speaker that was of interest was Mr. Victor Page.  He was from the DSDM Consortium and spoke about how DSDM is an Agile method that is becoming more widely used than it has in the past.  Mr. Page talked about how many believe that, by its name Dynamic Systems Development Method, that it is a method that tells you what to do and how to do it; however, he followed this statement by saying that it is more a framework than a method.  DSDM, as a framework, is more about showing what to do but leaving leeway in how to implement the framework.  Many, according to Mr. Page, are starting to ‘rename’ DSDM to “Driving Strategy; Delivering More”.

I was honored to speak to the group on day 1 about how teams are more than resources and they should be treated as such in a talk titled “Teams Are People Too”. In the 30-minute slot, I outlined how most teams are treated in traditional projects and how that treatment should be shifted when looking at teams in Agile.  I tried to point out how teams should be treated inside an agency, as a vendor-based team, and as a team that is split between an agency and a vendor.

In probably the most enjoyable session of the conference, I had an opportunity to participate in playing a round of the Agile Contracting Strategy Board Game developed by FWD Think.  This game is laid out similar to a cross between Monopoly, Trivial Pursuit, and Trouble.  Each of 4 teams, of 3 people each, roll a monster set of dice and move their ‘car’ around the board.  With each square the ‘car’ lands on, there are questions or challenges that the team must complete.  When a right answer is given or a challenge is completed, the team is awarded money.  Whichever team has the most money at the end of the game (in our case, the timeframe allowed to play), wins.  I found this game to be very helpful in understanding some of the nuances of Agile and acquisitions.  As an aside, my team of 3 won at our table!

As you can see from this short synopsis, there was a lot to take in and a lot to be learned in 2 days.  In all, there were approximately 120 people in attendance.  All-in-all, it was a very full 2 days!

Have you ever wondered exactly what types of things a team does during a Sprint or what they should be doing? A team usually has one thing on their mind during a Sprint: “complete our commitment”! However, there is a bit more wrapped in that commitment getting completed which the team needs to consider.

Something teams use to know if they complete their commitment is a Definition of Done. As a team develops their Definition of Done, they assume certain things, which frequently center on the most obvious like coding and testing, will be completed during the Sprint and base the Definition of Done on those. Nevertheless, there is much more that should be considered for the Sprint. By using what I call “The Sprint Bubble” as a guide, a team can construct their Definition of Done to ensure they do everything they need to do in order to complete their commitment.

In addition, by using the Definition of Done as a guide, the team will be much more comfortable with what they expect to complete during the Sprint and will identify things which should not be done. It is worth reviewing those as the team builds the Definition of Done as well.

A lot of teams think the Sprint is nothing more than a ‘mini-waterfall’-type timebox; which is not the case at all! While there are many things which go on during the Sprint, they are absolutely not done in a ‘mini-waterfall’ style. Using “The Sprint Bubble” (shown below), you can more easily identify the things that have a place, or not, in the Sprint. I like using the MoSCoW-based categories—“Musts”, “Shoulds”, “Coulds”, and “Won’ts”—to explain. These things, regardless of category, are simply a way to construct the Definition of Done. There are times when you may have a bit of order to be followed, but these things just need to be completed.

First, let’s look at the “Musts” that belong in “The Sprint Bubble”. The most obvious things are develop and test code. However, given that testing is usually broken out into multiple different types—unit, integration, functional, story, system integration, performance, user acceptance, and so on—there will be some that may fall into other categories. With that in mind, the unit testing and functional testing would be a must because they help to ensure the stories are completed and functioning correctly. Also, many teams are moving more toward story testing (also referred to as acceptance testing), which is defined as testing around each and every story to ensure it meets the acceptance criteria of that story. When teams are doing this style of testing, it is also considered a must. Another must is integration testing; teams need to ensure their pieces work together and integrate well in order to make sure the entire product works well.

What about things like design or user interface components? These would be categorized as “Shoulds”. Before we talk about what things are categorized as shoulds, what does it mean to be a should—well, it means that it is something that belongs in the Sprint, but will not necessarily cause a ‘break’ in the application that’s being built or overall Scrum framework if it’s not. A lot of what you find categorized as shoulds are designated as other teams’, or organizations’, responsibilities in larger companies but would be musts in companies that don’t have these other teams or organizations. When you have a company without these other types of teams, design or user interface components should be done inside the Sprint and be part of the team’s Definition of Done. When a company has a different team or organization that does these types of things, they may decide these things are to be done and approved prior to the story being put into a Sprint. The one thing that many teams seem to forget is documentation. Documentation is a should, and therefore belongs in the Sprint, which helps to ensure it never gets overlooked. Another thing that would count as a should is that of system integration testing. System integration testing is very important to the overall product and is required to ensure the newly created product plays well with what the organization already has in place.

That brings us to “Coulds”. There is some easy stuff that could be put into a Sprint based on the company and the ability to do it in the timebox. Coulds are things that some may argue belong in the shoulds, but the way the organization is organized or the way the environments are set up may more appropriately put them in could. Probably the most popular detail that falls into coulds is user acceptance testing. This is something that seems to have the most problem being put into a Sprint due to the amount of time that the UA testers can lend to the Sprint timeframe or environment setup. If you have none of these kinds of restrictions, the user acceptance testing can most definitely go into the Sprint and therefore will allow for a release to production after the Sprint. Performance testing is another could, but will also be done in bits as other types of testing are performed (another topic for another day). I try to have performance testing be more a should than a could, but again relies on how the organization and its environments are set up.

Well, now we are at the “Won’ts”. A few things definitely do not belong inside a Sprint and need to be defined as such. One of these is defining acceptance criteria for the stories already in the Sprint. If you do not have acceptance criteria on a story, then the story is not eligible to be put into the Sprint in the first place. Another is defining a story to work in the current Sprint. If a story is not well understood, it cannot be accurately estimated, which also means it cannot be worked properly and cannot be put into the current Sprint.

Hopefully by better understanding what work is part of a Sprint, a team’s Definition of Done can be better constructed and followed. By using “The Sprint Bubble” as a guide, it helps the team solidify what should be part of their Definition of Done based on their environment and company policies. Having a solid Definition of Done means the team can ensure they are producing the highest quality of a valued product at the end of each Sprint.

Occasionally, as part of our strategic advisory service, I work with clients who don’t want custom application delivery from us, but rather want me to provide advice to their own Agile development teams. Many of them don’t need a lot of help, but perhaps the single issue I observe most often is that iteration (or sprint, in Scrum terminology) planning meetings (IPMs) don’t go well. Rather than being an interactive exchange of ideas and a negotiation between developers and product owners for the next iteration, I observe that the IPMs become 2-week status meetings that don’t accomplish much. The developer team doesn’t have much or anything to demo, there’s little feedback from the product owner, and everyone just routinely agrees to meet in two weeks to go through the same thing again.

One of the main reasons for these lackluster IPMs is the failure to close tasks at iteration boundaries. If the developer team can’t close tasks at iteration boundaries, then the product can’t be usefully demoed, which means the product owner can’t offer any feedback. This isn’t any form of Agile – it’s just waterfall with 2-week status meetings.

Failure to close tasks at iteration boundaries has other implications too, because what it’s telling you is that stories are too big, and stories that are too big have big consequences.

First, big stories are hard to estimate accurately. Think of estimates as sort of like weather forecasts: anything over 2-3 days is probably too inaccurate to use for planning. The smaller the story, the more accurate will be the estimate.

Second, big stories make it harder to change business priorities. That may seem like a non sequitur, but when developers are working on any story, the system is in an unstable, non-functioning state. To change direction, the developers have to bring the system to a stable state where it can be taken in a different direction. Those stable states are achieved when stories are completed and the system is ready to demo.

An analogy I like to use is to think of the system as a big truck proceeding down a controlled-access highway, like an American interstate. You can exit only at certain points. If you’re heading north and you realize you want to head east instead, you have to wait for the next exit to make that direction change – you can’t just immediately turn east and start driving through the underbrush. The farther apart the exits are, the farther you’re going to have to go out of your way before you can adjust. Think of each exit as being the close of a story. The closer together the exits (the smaller the stories), the sooner you’ll reach an exit (a system steady state) where you can change direction.

In this series of blog posts, I’m going to look at what it takes to ensure task closure at iteration boundaries. Each post will focus on a different team role, and how that role can help ensure that iterations end in an actual delivery of working software that can be demoed in an IPM. I’ll write about what product owners, developers, and project managers (or Scrum masters) can do to reduce story size, ensure product stability and functionality at iteration boundaries, and keep the system always ready to quickly change directions – the very definition of agility.

Watch this space.

When people see my ­­business card or email signature, they sometimes question the letters beside my name: what do they mean,should they try to get them too, etc.  One set of those letters seems to jump out a bit more as a question than others – the PMI-ACP.  I think it’s because they see “PMI” and wonder what it’s about.  I’ve even had some people ask if it’s misspelled.  So, to clear the air, I’ll explain it…

The PMI-ACP is an Agile certification that is administered by PMI which signifies that you understand, and have experience in, implementing Agile methods.  There is a combination of an exam and the project experience you have in Agile projects to acquire the certification.

If you are still a bit confused, the Project Management Institute is considered to be the go-to source for all things project related.  As such, they are seen as the foremost authority on the processes that are used to deliver projects.  Over the last 5 years or so, as Agile has become increasingly the favored way to deliver projects, the PMI has added Agile to their Project Management Book of Knowledge (PMBOK) and added the PMI-ACP certification.

So far this doesn’t sound like much of a big deal, right?  Well, let’s see why it is…

As I mentioned, in the world of project management, the PMI is seen as the ‘governing body’ when it comes to ways to deliver projects.  Anyone that works on any project knows there are rules that PMI has set forth on managing projects.  Since the influx of projects using Agile processes, more and more project managers need to be apprised of the rules that change or the various ways that PMI has suggested instilling the Agile processes.

With the increase in Agile projects, there is a growing need for required guidance for these projects.  Companies are looking to their project managers and team members to gain the knowledge and expertise to ensure successful projects.

By having Agile experience and taking the exam, you too can acquire your PMI-ACP so that you can show your fellow project managers and team members that you have the experience and knowledge to help lead Agile projects effectively and successfully!

In order to acquire your PMI-ACP, you first should acquire the required experience in Agile projects.  PMI’s required number of hours is 1500 on Agile projects.  This can be done using any of the Agile methods and on multiple projects.

In addition to the project experience, you will need 21 hours of Agile education, which you can gain in numerous ways, including the PMI-ACP Exam Prep.

After you have worked on Agile projects, then you will need to take the PMI-ACP exam.  Now, most people get a little squeamish when talking about taking an exam, but I’m here to tell you not to worry!  There are many ways to study for the exam so that you can breeze through it, but the easiest being to take a class that will prep you for the exam.  Check out the PMI-ACP Exam Prep offered by CC Pace—it will give you an extra boost in your knowledge, your 21 hours of education, and some practice of taking an exam!

The PMI-ACP is seen differently by different people; some see it as just a set of letters while others see it as a way of exhibiting their knowledge of Agile processes, as accepted by PMI.  Either way, it is something that will most definitely show your team you accept the Agile mindset and are embracing the shift that project management has taken to follow the Agile processes!

In previous posts, I talked about what the “Get It Done” (GID) and “Just Do It” (JDI) patterns look like in organizations.  Today I’ll talk about another cultural pattern.

“MAKE IT SO”
If you’re a fan of “Star Trek: The Next Generation”, then you’re familiar with this phrase.  I can see it now….Captain Jean-Luc Picard standing on the bridge of the U.S.S. Enterprise, facing a situation requiring action.  He asks for options, listens to recommendations, and conveys a decision to move forward by telling the crew to Make-It-So.  His decision communicates “what” needs to happen, but he trusts the crew to figure out “how”.  This is the essence of a Make-It-So (MIS) culture, a pervasive attitude of leadership throughout an organization, resulting in an environment that supports growth, encourages exploration, demands excellence, and emphasizes accountability.

In an MIS culture, everyone has a place in the fabric of the organization….they are valued and valuable, and they know it.  Everyone has an important part to play….and they are expected to play it.  People are skilled and competent….and because they are, they’re confident.  People are empowered, they are “granted permission” to contribute ideas, to make decisions, to take risks…to “make it so”.

Ten characteristics I’ve experienced in an MIS culture include:

• Possibilities
  “When nothing is certain, everything is possible.” – Margaret Drabble
  We are informed by, but not tied to, what was.  We are grounded in the here and now, yet remain open to what could be.  We don’t drag ourselves down with visions of doom, but maintain a sense of hope and optimism.
• Focus
  “Concentrate all your thoughts upon the work at hand. The sun’s rays do not burn until brought to a focus.” – Alexander Graham Bell.
  When vision and purpose are visible and shared, it provides us context.  We know the direction and why, so we can act and make decisions accordingly.
• Interdependence
  “No man is an island, entire of itself; every man is a piece of the continent, a part of the main.” – John Donne
  We know it “takes a village” and we can’t do it alone.  Success depends on the combined strengths and contributions of everyone.
• Trust
  “The key is to get to know people and trust them to be who they are.  Instead, we trust people to be who we want them to be, and when they’re not, we cry.” – David Duchovny
  We trust in each other’s positive intent, and believe everyone does the right thing at the right time with the information they have. We act, make decisions, and move on.  While we reflect on what we learn from experience, we don’t undermine confidence by second guessing ourselves or others.
• Integrity
  “It’s not what we profess, but what we practice that gives us integrity.” – Sir Francis Bacon
  We seek to know ourselves, to be ourselves, to be proud of ourselves, our organization, our place in it, and our contributions.  Our actions are congruent with who we are, our beliefs, our passions, and our strengths. We own our decisions and choices, and their consequences.
• Discipline
  “Talent without discipline is like an octopus on roller skates. There’s plenty of movement, but you never know if it’s going to be forward, backwards, or sideways.” – H. Jackson Brown
  We strive for excellence, and excellence requires discipline in little things on a daily basis.
• Encouragement
  “There is no such thing as a “self-made” man.  We are made up of thousands of others.  Everyone who has ever done a kind deed for us, or spoken one word of encouragement to us, has entered into the make-up of our character and of our thoughts, as well as our success.” – George Burton Adams
  We grow through support and encouragement, which helps us spread our wings, improve, gain confidence, and reach our potential.
• Diversity
  “We need to give each other the space to grow, to be ourselves, to exercise our diversity. We need to give each other space so that we may both give and receive such beautiful things as ideas, openness, dignity, joy, healing, and inclusion.” – Max de Pree
  We know that too much sameness stagnates an organization, so we explore and leverage differences to open the door to possibilities.
• Courage
  “Courage does not always roar, sometimes it is the quiet voice at the end of the day saying “I will try again tomorrow.”” – Mary Ann Radmacher
  The rewards are greatest when we take chances, risk exposure, and step outside our comfort zone.  Leaders nurture and reward courage.
• Resilience
  “The secret of life, though, is to fall seven times and to get up eight times” – Paolo Coelho
  It’s not just a matter of having the will to get back up and keep on going.  We must also have the “health” to do that.  As an organization and as individuals, we take care of ourselves so we can continue to bounce back.

An organization which cultivates an environment like this, is one where people are important.  And when people are important, they collaborate, they innovate, they adapt quickly to change, they “dare greatly”…..and amazing things happen.

Gee, that sounds an awful lot like an Agile environment!

What do you think?

Are you competing on price?

Economists and finance executives world-wide acknowledge that being the low-price leader can be a viable short-term strategy that may help boost bottom-line profits but warn this is an extremely risky long-term strategy. Within the financial services industry margins are already squeezed and products continue to be distinctly vanilla. So what’s left when it comes to high-impact business strategies? Perhaps it’s time for business transformation by way of customer-focused differentiators.

Sometimes one doesn’t have to look beyond their local hotdog cart for inspiration.

Check out the accompanying photo. How is it that in downtown Denver while one hotdog vendor who charges $3.50 for a hotdog, chips and soda has no people at his cart, when a competing hotdog vendor less than 100 feet away has a line of people who are willing to pay $4.75 for virtually the same hotdog, chips and soda, everyday? Simply said, it’s called customer experience.

Meet Biker Jim. Jim Pittenger, a former repo man from Anchorage, Alaska, moved to Denver looking to open his own hotdog cart. Jim knew it wasn’t going to be easy. He was an unknown in the area and opened up several blocks from the main street, where competition was already entrenched. Jim recognized at the time that Denver’s most successful cart owner was occupying the premier location of cart real estate and essentially just had to ‘show up’ each day. If Jim was going to be successful, he knew he had to do things differently.

When I first met Jim, I shared how I had been analyzing his business and asked him to come down to the office to share his story. There, Jim explained, “I knew I had to set myself apart. I challenged myself to think about all the things I could do differently. Ultimately, I knew it would come down to focusing on the customer and the customer experience, and frankly, when I put my mind to it, it wasn’t hard. I sat down and made a list of the things I could do to make for a better customer experience. I studied not only what my competition was doing, I studied what they weren’t doing. I knew I wanted to build great relationships with my customers while making sure I created a great experience. Some of the things that made my list included cranking up some music that people could tap their foot to, and setting up a big umbrella that screams ‘something good is happening.’ I rigged my cart with some nice size exhaust pipes that would send the smell of my grill up and down the city streets. I added condiments that others didn’t, like grilled onions, sauerkraut and cream cheese. Giving the customer more options rather than just a plain hotdog with ketchup or mustard.” Jim went on to say, “Honestly, it’s really not about the hotdog, it’s about the experience.”

Joel Horn of Horn Funding Corp, a client of mine at the time put it this way, “The perceived value of buying a hotdog from Biker Jim is far greater than buying from his competition.” It wasn’t long after my interview with him that Jim’s chief competition was out of business and Jim was invited to take over the premier cart location in downtown Denver, the coveted corner of 16^th and Court Place. At the time he was still working the cart each day come rain, snow or sleet, but since then Jim has gone on to international acclaim and even greater success. Biker Jim has expanded his menu, been praised by the world’s foremost food critics and successfully launched into several retail locations.

What are you doing to re-vitalize your business in today’s demanding markets and vanilla products? What kind of customer experience are you building to spark the neural network like Biker Jim? Are you creating a customer experience like I experienced when I was in line for my dog and the guy in front of me called his buddy on his cell phone to make sure he was at the right place? What’s your customer-focused business transformation strategy? Joel Horn summarized it best, “Regardless how bad things are or the amount of fear inspired by the media, if you have your customers’ best interest in mind when creating your long-term vision, you will succeed!”

I spend a lot of my time coaching individuals, teams, and organizations interested in reaching higher levels of performance through the use of Agile methodologies like Scrum, Kanban and SAFe. Some clients expect me to tell them what to do step by step, while others are interested in learning how methods work so they can determine what practices to use as their circumstances evolve. The approach that leadership teams prefer usually reflects the problems they are trying to solve, as well as their domain of expertise, their size, their culture and their organizational purpose (for-profit, non-profit, government, etc).

In conversations with leadership teams, we discuss patterns and practices they could help institute or amplify in order to sustain their Agile transformation journey.  Our message, reinforced by all success stories in the industry in the last 15 years is clear: The success of an Agile transformation, regardless of the practices adopted, is directly proportional to how well people in leadership roles at all levels understand, exercise, and constantly improve their Agile mindset.

Leading with an Agile mindset means letting go of the traditional notion of leadership as strategy and control from the top according to a pre-determined plan of action. In times of rapid change when high levels of complexity and uncertainty are the order of the day, leaders can no longer assume they can know or control what goes on. Individuals at all levels must adapt constantly to changing conditions using their best capabilities and judgments in the moment.

In these circumstances, the role of leadership in Agile organizations is to shape the understanding, development, and learning of team members so they can act both independently and in concert with the goals of the whole organization. Leaders need to become coaches, coaching across the organization as well as individuals:

• Individual Coaching: You institute a style of leadership that is participative, servant, transparent, and unleashes the intrinsic motivation of a workforce that seeks mastery in their respective skills
• Organizational Coaching: You focus on understanding and managing the organization as a whole, optimizing the interdependence of teams and departments in order to minimize waste and maximize effectiveness

In practice, we observed that effective leaders in Agile organizations are also effective coaches. I constantly meet people who have a natural coaching mindset and they don’t even think of what they do as coaching. Here are three definitions and models of coaching that have emerged in recent years:

• Coaching is a process that enables learning and development to occur and thus performance to improve. To be a successful Coach requires knowledge and understanding of process as well as of the variety of styles, skills, and techniques that are appropriate to the context in which the coaching takes place.– Eric Parsloe, The Manager as Coach and Mentor
• Coaching is unlocking a person’s potential to maximize their own performance. It is helping them to learn rather than teaching them. – John Whitmore, Coaching for Performance
• Coaching is an interactive process through which managers and supervisors aim to solve performance problems or develop employee capabilities. The process relies on collaboration. – Richard Luecke, Coaching and Mentoring

Leaders in Agile organizations understand that coaching creates a learning environment where individual and collective challenges are the first priorities. Coaching skills enhance their management tool-set in a way that benefits themselves, their staff (those who are coached), and their organizations.

Trust – The Foundation of a Coaching Relationship

Trust has been defined by some as the ability to be vulnerable (Schooman, Mayer, and Davis, 2007). Implicit in this definition is the assumption that when you trust someone, you’re willing to be open, less guarded about your weaknesses and more candid about your opinions and ideas.

In his 1993 dissertation, A Construct of Trust,  Dr. Duane C. Tway, Jr. defines trust as “the state of readiness for unguarded interaction with someone or something.”

And in Rhetoric, Aristotle, 384-322 BC), suggests that Ethos, the Trust of a speaker by the listener, is based on the listener’s perception of three characteristics of the speaker: competence (correctness of opinions), character (reliability – a competence factor, and honesty – a measure of intentions), and the goodwill of the speaker (favorable intentions towards the listener).

When a manager uses a supervisory approach, the relationship between the manager and their subordinates is based on expertise. Boundaries are strictly maintained. Trust, while relevant, is not a key component. The relationship is embedded in the hierarchy of the organization.

When managers coach, the relationship between them and their subordinates is based on both expertise and on abundance of trust. Subordinates trust their managers to do the right thing for them, for themselves, and for the organization.

Samuel B. Bacharach, director of Cornell University’s Institute for Workplace Studies conducted extensive research and wrote over twenty books on management, organizational behavior, and industrial relations. His research indicates that organizations that do not embrace a coaching culture perpetuate a static culture of inertia, bureaucracy, and control. In contrast, coaching is a characteristic of organizational cultures that value innovation, creative thinking, problem solving, growth, and change.

Bacharach points out that “a coaching relationship requires that the protégé (the person being coached) views the coach as someone who possesses the expertise of a good supervisor, but who is simultaneously as trustworthy as a good friend. This combination of expertise and trustworthiness composes the personal integrity of the coach. The more your protégés believe in your personal integrity, the more committed they will be to you, and the greater the likelihood of your success as a coach.”

In another study, C. Ken Weidner, an assistant professor at the Center for Organization Development at Loyola University Chicago, found that trust in the supervisor is associated with better individual performance.

You don’t need to be a trained professional coach in order to include coaching in your set of Agile leadership skills. You have to be able to tell your employees “I know how to do it,” or, “I’ve been there and done that,” without giving them the impression that you think you know it all. To establish or amplify trust, Bacharach recommends you let your protégés know that:

• Confidentiality is the golden rule
• You have their interests in mind when making decisions in the workplace
• They have the ability to speak freely to you
• You are open to learning new things and some of those things can be learned from them

Trust is the foundation for coaching relationships. It is also the foundation for what you want your organization to become.

The Supervisory and Coaching Mindsets

Both coaching and supervisory relationships exist within the hierarchical dynamics of an organization, yet they are fundamentally different.  A coaching relationship temporarily suspends the hierarchical structure, and is a partnership based on the candid, free-flowing transition of ideas and information between coaches and their protégés, which serves to support, reinforce, and motivate both.

Coaching holds that employees potentially possess the best answers to the problems they are faced with, and that the coaching process helps them discover the sources of those answers within themselves.

Leading involves both supervising and coaching. As a proactive manager or leader, you perform each of these two different roles, and each is characterized by its own mindset. Moving between these roles requires a subtle mind shift. Here are several examples:

Let’s look at several examples of how a supervisory mindset or a coaching mindset can influence the way we communicate with others:

• “I suggest you complete your work in the order that you receive it.” – The supervisor focuses on coordinating work rather than facilitating it.
• “Since our last scheduled meeting, you’ve been doing a good job. Keep up the good work.” – This statement is an evaluation of job performance and is characteristic of a supervisory mindset. There is no suggestion of a plan to develop skills together or of a partnership, both hallmarks of the coach-employee relationship.
• “I understand the tight deadlines, the constant pressure from customers to provide the best service, and the intense competition that are all a part of your job. How do you think we can continue to improve the organization and ourselves given these conditions?” – This is a coaching statement. The speaker is empathetic and shows expertise regarding the current situation. The speaker indicates an interest in partnering with the direct report.
• “Working closely with you is very helpful, because not only do you improve on your abilities, but working with you also enables me to isolate those areas that seem problematic in general for employees in your position.”  – The sense of partnership communicated here indicates a coaching relationship.
• “I appreciate your coming to me for assistance. It takes a lot for people to recognize their limitations and to know when they need to seek advice from others. In my experience, there are a few different ways we can approach solving this problem, so let’s work together to think of a feasible, realistic, and desirable solution.” – The sense of partnership communicated here indicates a coaching relationship.

Next Steps

Mindsets like Agile Leadership and Coaching are critical to the success of an Agile transition in your organization.  It takes practice to be good at them, and that means you have to go out there and do it. If, in the process of coaching, questions or challenges come to mind, we’d be delighted to hear from you.

If you read this far, you probably enjoyed this article and I hope it stimulated ideas you can start using at work.   I greatly appreciate your curiosity, and hope you stay in touch! Let me know if we should expand on this topic or if there are other topics that you would like to read about.

Before heading down to Ruth’s Chris for our Annual Winter Party, CC Pace President Mike Gordon spoke at our corporate staff meeting and rolled out our business plan and new initiatives for 2015.  Our corporate staff meetings give us an opportunity to bring employees together from our main office and various client sites to share what is going on with CC Pace and provides a great time to catch up with colleagues.

Immediately following our Staff Meeting, we headed downstairs to Ruth’s Chris Steakhouse, conveniently located on the first floor of our building.  Our Annual Winter Party is a rich tradition that began at CC Pace years ago.  We once held our parties in December, renting out ballrooms at local hotels and other venues for the event.  One year, a hotel lost our reservation and we had to hold the party in later months.  The holidays are a very busy time of year and we found that having the party in the first quarter of the New Year actually served us well.  Generally, there is less going on during this time of year and things are less hectic and we found that people enjoyed the new timeframe and we had higher attendance as a result.

Big hits at this year’s party included seared tuna, beef tenderloin, sliders, and a great selection of decadent desserts!    It was a great evening to share with employees and their spouses.  The planning was done by our very own Staffing Manager, Laura Campbell, who did a great job of organizing the event.  We are already counting the days until next year’s party!

Mike Gordon addresses the company during our staff meeting

Jason and Clay kicking off our annual party!

Everyone enjoyed great food and conversation!

Scrum purists will tell you co-located teams are the way to go. If only it was that easy!

As large organizations adopt scrum, they find themselves struggling with how to be more Agile when many of their teams are distributed. As coaches and trainers, it is our responsibility to support this reality.

There are many blogs and articles like this one on the web that talk about working with remote teams.

Many of the articles I see offer common sense tips like:

• Make the most of tools for instant messaging, video conferencing, and shared content.
• For ceremonies, use video conferencing whenever possible.
• Ensure Team Agreements, Definition of Done, and Definition of Ready are in a shared location.
• Team Agreements need to include core hours when everyone will be on instant messaging.

Here are some of my own more unique suggestions:

• Dealing with time zone differences – Although ceremonies should be at the same time/place whenever possible, consider alternating times by month, or sprint. For example, on odd months favor east coast times, while in even months favor west coast times.  Don’t do too small of an increment (like daily).
• Time for a celebration – Ensure everyone on the team, regardless of location, goes out and celebrates. Schedule an extra 15 minutes post scrum to discuss what everyone did. Get creative….hold virtual “coffee breaks” or “pot lucks”; celebrate personal events (such as birthdays, births, leaving, etc) as well as team accomplishments.
• Tracking Sprint Progress – Utilize your tools’ dashboard during daily scrums to show the teams burn-down. Don’t micro-manage tasks. Insist team members keep tasks up-to-date reducing ETC to keep burn-downs current.
• Product Owner – As a Product Owner (PO), engage fully with the team to ensure collaboration leads to comprehensive understanding of each story. Ask questions. Update stories in real-time during team grooming to clarify understanding. It is easy to leave PO acceptance of stories until it is too late for developers to make changes. Instead keep an eye on story progression, review stories as soon as they are ‘done’.
• ScrumMaster as team facilitator – As a Scrum Master (SM), your role is especially important with distributed teams. Pay attention to how members interact. Is everyone participating in ceremonies like grooming and planning? Ask questions to draw out quiet members. Also, just because you are the facilitator, doesn’t mean you have to “be in charge”. Don’t forget to turn items like tasking stories over to developers. Just sit back and listen while they do the work.  Consider a SM for each location (e.g., if you have part of the team together on the east coast and another part together on the west coast, use a SM in both places).

There’s no doubt about it…..it’s harder for remote teams to achieve the same collaborative environment that co-located teams can. But it’s not impossible….with a little elbow grease and TLC, your distributed team will shine!”

I was recently reminded of a column I wrote back in February 2008 titled “Maintaining a Vendor Relationship”, for Mortgage Banking Magazine (available here).  I’ve been working on multiple system selection efforts of late being driven by proactive customer decisions to look at options available in the marketplace. These efforts have been driven by dissatisfaction with the current vendor but without pressure of a looming deadline or need for immediate change.  In most cases, the dissatisfaction came after the vendor/product was acquired by a larger organization changing the dynamic between client and vendor.

The recommendations I outlined in that well-aged column included:

1. Identify your vendors
2. Know the contractual highlights
3. Maintain open communication
4. Leverage the partnership
5. Maintain documentation
6. Validate escrow
7. Increase internal resources
8. Do market research

And while these recommendations are still valid today, they don’t fully reflect the new landscape of the consolidated marketplace where there are few independent vendors with a single, focused product offering.  Most vendors these days are part of larger conglomerates, with seemingly deeper pockets to support innovation, who have created through acquisition a portfolio of offerings to their financial services clients.  In some cases this includes multiple solutions addressing the exact same (or very similar) functionality, possibly, but not always, targeted at different customer segments.

So what does this mean and how does it change things?

In today’s market, there are additional recommendations needed to manage the vendor relationship.  These address the more complex organizational structure, the focus of those organization (and where those deep pockets may be utilized) and looking further ahead, not only for the product you’re using, but for the overall vendor objective.   Let’s face it, your vendor’s move from a sole product offering to being a small fish in a larger pond is a culture shock not only to your relationship, but to the staff supporting the product, as well.  There is a lot of change to be managed and it’s important to stay on top of it.

• More layers of communication: While open communication is still important, there are more options for who you might communicate with.  Obviously the product support team is key to the upkeep of service levels and current enhancement plans, but there should be connections maintained up the ladder.  This group may not be fully in the know on the long-term strategic plan for the product or the organization.  Do not wait until there is an issue to figure out who the contacts outside the product group are, and do not let the relationship languish in order to avoid reaching out, only to find out that they have left the company or moved to another position.  Within a large organization, much can happen without direct communication, so keeping these lines open increases the likelihood you will begin to hear murmurs and can make plans, prior to announcements being fully communicated or distributed.
• Networking: It is more important than ever to keep your connections alive.  These can include other users of the platform, or people who developed or supported the product.  It is always good to have someone to share stories with, and ensure things are progressing in similar patterns for everyone. Working in concert with other users can help to influence the vendor towards a particular direction or implement needed enhancements.  Knowing the people who really “know” the system, provides a possible back door to address critical issues that the current support organization may be struggling with.
• Awareness of where the organization is making investments:  If the consolidated company claims four LOS’ within their portfolio, it is extremely unlikely that each LOS is receiving similar investments for future improvements.  Identify which product and/or customer segment has the focus, and determine the implications for support of your solution when it is not the focal product.
• Be modular: It is more important than ever to retain your flexibility when it comes to the ability to switch products.  Vendors being acquired and the direction new owners take a product are outside your control.  What is within the control, is the level of effort and ability to switch vendors when needed.  Within the mortgage industry, MISMO for services was lauded as a tool lenders can use to more easily switch between providers.  Similarly, the recommendation is to standardize the requirements for any feeds to your systems via a connector-based process.  Products would feed/receive data to/from the connector, rather than directly into the internal system.  This allows the system on either side to be exchanged, without a direct impact on the other system or the resources supporting it.  This reduces the risk and effort when replacing systems, as they only need to connect to the connector; the programming which directly impacts that system is unaffected.  In addition, should the vendor make a change that could impact your systems without realizing it, the data would be likely stopped at the connector and not impact your internal systems.  Today, much of the integration is directly system to system, requiring a full re-development every time either system changes.   The connector approach reduces the level of effort needed and resulting testing that will need to be completed.  The connectors also offer re-usability for different purposes.  Internal resources to develop and support the connectors are needed, but in most instances the long term peace of mind and time savings will balance that investment.
• Be Diligent:  A vendor with a wide portfolio has a lot to offer, but it is important that additional offerings are approached wisely.  With a lot of growth coming from consolidation and not organic expansion, it is important to complete a thorough due diligence of all offerings.  Do not assume anything!  Do not assume that because the same vendor offers both products, the products are tightly integrated.  Growth through acquisition results in potentially disparate solutions carrying the product name.  Don’t assume because products have same or complementary names, they are connected. Product name changes are marketing ploys to create the feel of a suite of offerings, whether the connectivity between products is in place or not.  Do not assume that because your product is well supported, that any additional platform has similar support.  Each product may have separate support staffs, with different levels of competencies and knowledge.  Do your homework and complete a due diligence exercise extending into the marketplace with competing solutions to determine if the vendor solution represents the best solution for your organization.

There can be significant benefit to you through acquisition of your vendor by a larger organization, or not.  It is a matter of what that organization’s plans are, how they are managed and where their investment is being placed. Stay informed and be proactive is the best advice.

In a prior post, Getting Ready for Your Technical Transformation, I defined technical transformation and why it is so important.  Now, I’d like to dive a bit deeper into some tips on going about it…

To begin to transform your technical ‘world’, you need to first make sure your organization’s environments are aligned. As a start, the technical experts in your organization should decide what environments are necessary to deliver the value to the customers; sometimes it could mean as few as 3-4, and sometimes 10-12 may be more like it.  The idea here is to build only the environments which are required and leave the others behind; the more environments your organization has, the more attention and costs that will need to be given to them.  When you have more environments, you vastly increase your costs in areas such as physical hardware, bandwidth, cloud storage, software platforms, which also calls for an increase in cost to administer and configure these environments.  It is wise to plan out the environments carefully!

From what I have seen, and know from my experience as a developer, organizations can usually get by with 4-7 environments, such as “Development”, “Testing”, “User Acceptance Testing”, “Staging”, and “Production”.  A couple of these may be combined or broken out in some organizations, depending on who is doing the acceptance, if there is training to be done, or if there is any beta-type testing needed, but remember that the more you have, the more work they require!

The point is to have the environments, regardless of how many you have, be aligned with the delivery, meaning “Development” would be used for team member to write code, write test scripts, etc., while “Testing” would be used to run stable code, execute test scripts, etc., with a constant set of data to check for bugs, “Staging” would be used to smoke test everything before it is put into “Production”, and so on.

Once the environments are established, the next question is what to do with them and how to move the product through them to “Production”.  There are numerous ways to do this, and the ‘go-to’ way is by manually copying the product between them or even rebuilding the product in each environment.  However, by doing these manual processes, the move is prone to errors—anytime you insert manual, people-driven processes, you introduce error.

In order to eliminate as much error as possible, it makes sense to have machines do the moving.  This process is referred to as “Continuous Delivery”.  You can make this happen by utilizing tools that are out there to help with this very thing.  Some of them you may want to explore are: Jenkins, TFS, Ant, Gradle, Bamboo, or Puppet.  While these are a start, there are many, many others tools to choose from.  The selected tools will depend on your preference, i.e. if you are a person comfortable with scripting/coding or someone who feels better about checking boxes and clicking buttons.

These tools will help you move the product through the environments to “Production”, but they will also help you with another key aspect of transformation:  continuous delivery of each product increment.  To complete an Agile transformation, including the technical ‘stuff’, you really need to be able to deliver continuously to each environment.

Any organization that feels it has truly become Agile will hold to the true nature of Agile:  iterative and incremental delivery.  If this is the case, then it stands to reason that you need to be able to continuously deliver product, pretty much on demand.

If you get stuck and are not sure what to do, you can always call upon a Technical Agile Coach—they can help you align your environments, choose the right tools, and even get you delivering continuously!

As you many have read in my prior post about The Agile Impact regarding “Telework and Modified Schedules”, there are some variations on how moving to being Agile has impacts on the government agencies that are different than those seen in private industry.  In this blog, I will highlight some of the impacts that contracts and vendors have on the Agile transition in government agencies and outline some things to watch out for.

To set the stage, I first want to point out that we are not examining the contracting styles or types, but we are looking at how having most of the team members being outside of the agency, working for a vendor which is based on a contract, changes the landscape of how Agile is seen and implemented.

Before we get too far into the impact to the agencies, let’s set the stage a bit on what an Agile team really is: dedicated!  You can read more about the definition of an Agile team by reading another post: “The Reality of T.E.A.M”.  In short, an Agile team is formed with the intent of being dedicated to the team and to the solution they are delivering.  The team is intended to be created so that they remain a team, even after the release happens.  An Agile team is not created around their specialties, but more by pulling specialties together and having them work together to accomplish a goal.

Now that I’ve set the stage on what an Agile team is, let’s dive into the impact agile has on contracts and vendors…

In many government agencies, the teams that do the work building the solution are typically not government employees, but rather they are employees or contractors of a vendor that has won the contract.  These teams will sometimes be allowed to sit at the agency, but more often I’ve seen that they will be offsite, either at the vendor’s office or at their home.  This style of team poses a few issues when comparing to the definition of what an Agile team is.  Any ideas on what some may be?

When a contract is awarded to a vendor to build a solution, they usually go form a team to complete the contract.  In most cases, the vendor will assemble a team that has the skillset they need to complete the solution.  This team, which probably will not be sitting within the agency, needs to be able to communicate and collaborate with people within the agency on a daily basis.  This poses a number of issues since they are not co-located and most likely not on the same network.  It becomes a challenge for the team to be as effective as they can be; the team needs to work much harder to communicate and collaborate.  When this happens, communication and collaboration have a tendency to fall away and take a back seat to ‘just get it done’.

Also, when a vendor has their own team, which is not affiliated with any particular agency, the team in all likelihood has their own way of doing things and their own ‘set of rules’.  The team’s way of doing things may not align with the way that the agency does things, but they will need to find a way to work together.  If they don’t figure out how to work together, they will never really deliver the value requested.

Another hiccup in the vendor-agency relationship when moving toward Agile is the constant need for the agency to evaluate the team according to the contract.  While the vendor may understand the shift from a ‘contract-based’ relationship to one that is more ‘collaboration-based’ (see value 3 of the Agile Manifesto), they are still responsible for delivering the contract.  This puts the team, based at the vendor, in a bit of an interesting position: do they collaborate and deliver based on the communication/collaboration OR do they follow the letter of the contract and deliver based on that?  I’ve seen a couple instances, not many however, that manage to have both, but it really depends on how the contract is written and how the vendor’s relationship is maintained.

In most instances, the agency’s relationship with the vendor relies heavily on the contract and ensuring the things outlined in the contract are what are delivered.  However, the vendor and the agency can find ways to accomplish both – an Agile transition AND delivering to the contracted agreement.  The biggest thing they both need to keep in mind is that they need to communicate and collaborate in order to ensure both the value and contract are the drivers.

One of the easiest ways to ensure that both the transition and contract are met, is to have a vendor that understands and supports being Agile.  When a vendor is already aligned with the Agile values, it makes things much easier to ensure the communication and collaboration are the basis for the delivery.

In my last post, I talked about what a “Get It Done” (GID) pattern looks like in organizations.  Today I’ll talk about another cultural pattern.

“JUST DO IT”

Many of us are familiar with “Just Do It” as a Nike ad campaign, which began in 1988…egad! I can’t believe that was over 25 years ago!

Although Nike (which, go figure, is the name of the Greek Goddess of Victory) got inspiration for their famous slogan from the final words of a serial killer (“Let’s Do It”), their ads resonated positively with the public because the simple words and imagery reflect our uniquely American values and spirit.

Be strong. Be bold. Be first. Be victorious. Do something. Do anything. Start now.

That spirit is at the heart of a JDI culture, a culture that focuses on and rewards starting.  A culture that plays to our passion, our confidence (some would say arrogance), our desire to win, and our innate belief that we will prevail under any circumstances.  Success and the American Dream are ours if we take action, work hard enough, and persevere.  This is where we come from, it’s in our national DNA.

So what’s wrong with that, you say?

Well, there’s nothing wrong with it, exactly.  It’s as American as baseball, mom, and apple pie.  But is it a good fit for Agile?

I’ve worked in many JDI environments; it was exciting, I enjoyed it, and I learned a lot.  Most first-responder and mission-critical jobs depend on people just-doing-it.  It requires the ability to adapt and make quick decisions while not having all the facts.  It’s fun, challenging, risky, and satisfying to plunge right in and get your hands dirty.  What’s not to like?

But it can also be stressful.  There’s an expectation to try harder, to do more, even to be perfect.  There’s often an element of competition, and a feeling that if we stop to rest, we’ll fall behind.  Adrenaline pumps through our body in response to the challenge of walking an ever finer edge, ready to spring into action, climb that next mountain, turn around that troubled project, or conquer the world.  We have the freedom to move fast, but not the freedom to fail.  Always, there’s the awareness that if we’re not up to the challenge, we’ll be seen as weak.  And as President Lyndon Johnson once said, “The American people will forgive you anything except being weak.”  While some of us can thrive in this kind of environment forever, for most of us it’s not sustainable for the long haul.  We burn out, or wear out, over time.

Lest I be misunderstood….starting things IS important.  As is passion, confidence, and the ability to adapt quickly and act in the face of uncertainty, to not be paralyzed by indecision.   These characteristics of a JDI culture are also essential to Agile delivery.

It’s just that in a JDI culture, the scale tips toward the un-Agile characteristics.  Like runaway WIP, because it’s more exciting to start the next new thing than it is to finish what’s already in progress.  Like fatigue, because the pace is not sustainable. Like an obsession with success, because there’s a low tolerance for failure. And like an emphasis on “I can do” over “we can do”.

An Agile change initiative would certainly start with a bang in such an environment; and would likely lose momentum before finishing.  An appropriate balance is needed to create change, respond to change, and sustain change.  And a JDI environment is out of balance.

So that’s my story and I’m sticking to it…..what do you think?

CC Pace uses the Organizational Component Model as a framework for ensuring optimal results are achieved in our projects.  The model highlights the inter-dependencies of process, technology, and organizational roles and responsibilities, and how that interaction is critical for optimizing the benefits of change within the enterprise.

Ideally, these three components work in harmony to support achievement of the strategic plan and in reaction to the business environment. The critical point of viewing business structure in terms of these three components is the realization that you can’t introduce change in one component without affecting the others. Importantly, the realization of the intended positive benefits of introducing change into any aspect of the business can in fact only be realized by considering the resulting effects on the three components and adjusting each to embrace the change. A brief discussion of the individual pieces of the model is helpful to understanding this paradigm.

A company’s business environment is best understood as those external influences whose very existence requires the company to operate in a certain way to succeed.  Unable to change or control the environment in which it operates, a company must find ways to operate within its parameters. This is typically done in the context of a Strategic Plan, the documented direction and goals of the firm that take into consideration both the corporate vision and the effects of the environment within which it operates.

The operational processes the company employs serve to establish an effective and efficient means to accomplish the operating needs expressed in the plan.  These processes are typically designed by analyzing inputs and desired outputs, and mapping out the process logic and business rules, initially with only limited consideration of supporting technologies or the people in the organization.

With the optimal operational structure documented, the next consideration—the second component of the model—is to develop suitable technological solutions that serve to enable the operating processes.  The objective of this component is typically to automate those processes that rely on a “do” mentality (versus a human “think” mentality).   In some cases, companies can utilize existing technology solutions already in place to accomplish this objective.  In other instances, technology solutions need to be developed and implemented over time to enable achievement of the desired operational results.

The final component of the model is the company’s organizational structure, along with the roles and responsibilities of management and staff.   Bringing the operation to “life” depends on creating the necessary structure and hiring and training the right people to make the organization run effectively.

Successfully effecting operational change of any magnitude requires that companies understand the inter-dependencies intrinsic in this model.  Attempting to introduce meaningful change by revising only one of the components is too often viewed as an easy means to an end, but this approach more often yields a high level of disappointment or outright failure.  Understanding that all the components need to work together to support change, and taking the appropriate steps to address the needs of each, increases an organization’s chances of being successful.

This model provides the framework for a rational and effective approach to change. By understanding the company’s environment and desired strategic direction, the interlocking components of Operations, Technology and Organization can be developed to work effectively together to accomplish the corporate objectives.

As your organization prepares to transition to an Agile one, you will most likely want to know all that the transformation entails.  One of these things will be transforming your technical practices to better align with the Agile Engineering Practices…so how can you make it a success?

Plan For It 
Organizations typically will look at the process, the teams, and the projects they will transform in their move to Agile.  However, they often forget a key piece of the puzzle: the technical ‘stuff’.

In the scheme of things, it is fairly easy to change the process that one is doing from process A to process B.  It’s also relatively easy to choose the projects that will move to Agile and the teams that will work on them.  The hiccup is that they almost always forget about the changes that must be made to the technical architecture they have in order to ensure the complete transformation.

Identifying the technical changes that need to be made and ensuring they are part of the transformation plan are keys to making your agile transformation a success!

Architecture on the Brain
In most organizations, the technical architecture is one that is usually aligned with projects or, sometimes, aligned with what was pushed and when.  The architecture is most likely not aligned with the various applications or features that the organization produces.

When this is the case, the teams most likely will have a difficult time aligning themselves in a way that they can concentrate on any specific application or feature.  This concept produces issues for teams’ ability to work on a defined backlog, and even worse, creates barriers to them completing anything of value during a sprint.  This type of architecture is steeped in dependencies and blurry lines.

In order to ensure the architecture is set up to allow for the Agile Engineering Practices, it is imperative that the architecture be examined and plans be made to make the necessary shifts in the alignment of the architecture to match.

What About Environments?
Environments are another aspect that can cause issues when attempting to institute Agile Engineering Practices.

There are usually multiple environments, like DEV, QA, SIT, UAT, and PROD, that the team will move their completed increments through.  The biggest concern with this is that most of the time, the environments do not match up and they have varying states of the application and data.  This poses numerous obstacles to the team being able to produce effectively.

To deliver value effectively, teams need to be able to accurately test the stuff they are producing.  In order to accurately test, they need to have a “clean” environment to move their increments into.  When environments are not in sync and/or are not aligned correctly, teams will have issues creating successful builds and testing them.

When the environments are not correctly aligned and/or they are not working properly, there are major consequences that can result.  These consequences can range anywhere from not completing a sprint’s increments to producing low quality results to ending up with unwanted value.

A Couple Things to Think About
If an organization doesn’t identify and plan for the technical architecture changes they will need to support their Agile transformation, they will most likely cause more delays and, more importantly, pose more barriers to the team’s effectiveness.

Examine what your team has in its way when it comes to developing, testing, and deploying code.  What kinds of measures do you feel your team needs to take in order to deliver value on an incremental, consistent basis?

Stay tuned for the next installment where we will look at ways to make the technical transformation a reality…

On January 28, CC Pace and the Potomac Forum collaborated once again to present their latest in the series, Agile Development in Government Training Workshops.  In addition to CC Pace’s presentations and training sessions, speakers and panelists included officials from the Department of Homeland Security (DHS), the National Geospatial-Intelligence Agency (NGA), and the Government Accountability Office (GAO).  Several other Federal agencies were represented in the audience.  The workshop participants were challenged to take a fresh look at what agility, “being agile”, really means.  One top Federal official posed five questions for us to consider:

1. Can we have a Lean bureaucracy? If you had one more incremental dollar for your project, what would you spend it on? Right now we’re spending that dollar on oversight and documentation instead of valued results.
2. Shouldn’t we be looking at best practices, cutting edge approaches instead of arguing about Waterfall vs. Agile?
3. Why not benchmark to leaders in Industry like Netflix and Amazon?
4. Why doesn’t top IT talent think the Federal government is the best place to work?
5. Why is it acceptable to spend billions of dollars and take forever to build software?

One of the key Agile principles that was emphasized throughout the day, both by CC Pace and the government officials, was the value of empirical learning.  By building software incrementally and taking advantage of short feedback loops facilitated by continuous communication with end users and other stakeholders, the developers can apply what has been observed and commented on to improve the process and more accurately inform the schedule, requirements and production as they go forward. This approach greatly reduces project risk while improving quality and usability of the finished product.

Officials from some agencies that are successfully implementing Agile practices already, cited recent initiatives like the publication of the TechFAR, and the Digital Services Playbook, as well as the establishment of GSA’s 18F (a Federal Agile services group), that are beginning to remove some of the roadblocks to agility in the Federal Government.  Since there were a number of workshop participants who were new to Agile and Lean Thinking, CC Pace included an excellent session on Agile Basics, laying the foundation for our working lunch session,  What challenges will your agency face when trying to implement Agile?  The working groups came up with five common challenges: 1) Cultural resistance to change, 2) Regulatory issues (all the way up to Congress), 3) Old measures that may not be relevant in the new environment (EVM), 4) Need for training of executives and middle managers, and 5) Inability to attract top talent to government from the private sector.

Our panel discussion included comments on these five issues as well as on the fact that Waterfall project failures have soared into the billions of dollars over time.  There has to be a better way.  However a note of caution was sounded since many vendors are claiming “agile” when there is nothing agile at all about their approach. Agile is not a “silver bullet”.  Agile is not going to fix a poorly managed project.

CC Pace wrapped up the day with a presentation by their Federal Practice Director on cutting edge practices in Lean and Agile in the session What’s on the Agile Horizon and Why it is Important for Government, followed by the final presentation Putting it All Together – An Agile Roadmap, by CC Pace’s Managing Director.  The workshop received excellent evaluations from the participants.  We hope you can join our next Agile in the Federal Government Workshop at the Potomac Forum this coming spring.

This is typically the time of year that everyone is recovering from the holidays, not only financially but physically.  On average individuals can gain from 1-3 lbs. over the holiday season.  That might not seem like much but over time this can add up quickly and is considered a major contributor to obesity later in life.  Making even the smallest adjustments can make a huge impact when you are trying to get back into shape, taking the stairs instead of the elevator or parking further away from your destination, both can help you get in a few extra steps.  Eating breakfast is also an important step you can take to maximize your weight loss.  Researchers at The National Weight Control Registry found that individuals who ate breakfast every morning were not only able to lose weight quicker but also able to maintain the loss for at least a year and some as long as six years.

As part of the CC Pace Health and Wellness initiative we have started offering our employees healthy snacks and fruit to enjoy throughout the day.  We have also put up a Health and Wellness bulletin board in our kitchen that lists some helpful tips about staying healthy, eating right and reducing stress.  The HR department is busy looking into many possible events for the upcoming year such as, guest speakers, healthy pot lucks, and some contests to inspire some friendly competition.

We want to make it fun and easy for our employees to maintain a healthy lifestyle. Making just a few adjustments can help you get back on track; after all, summer is right around the corner!

In the first installment of this blog entry, we laid out a scenario which portrays an unhappy software development team. It has become obvious that developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Testers are also becoming frustrated as they are seemingly wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

At this point, if they haven’t already, the daily stand-up meetings and/or retrospectives, have most likely taken an on an ornery tone. It’s become obvious that time is being wasted and team members are unhappy.

One potential solution? The post-deployment demo.
I have seen in MANY cases that a significant amount of these issues can be identified up-front – before the retesting effort even begins – by simply scheduling an informal “post-deployment demo”. The format is similar to the aforementioned sprint demo, yet in this case, the “presenter” of this demo is the developer(s) who have worked on the fixes, and the “customer(s)” are the testers actually testing the fixes. The goal of the demo is simple and also similar to the sprint demo – the “customer” should leave the demo confident that the foundation of work which was completed to fix each defect is complete and satisfactory.

Basically, we can attempt to answer two important questions – first, “have we truly fixed what we said we’ve fixed? Second, “have we fixed what actually needed to be fixed and not clearly broken something else in the process?” The second question is obviously a lot more difficult to answer.

It’s important to keep the deployment demo as informal and efficient as possible, yet consistent. Ideally, if accepted by the team as a valuable practice, it should become a team norm, thereby making it repeatable. Usually, QA deployments are on a set schedule; in this case, the demos should adhere to that schedule. Demos should not be considered “painful” because over the course of a project, significant time and effort is saved when issues are uncovered and agreed on between testers and developers before the issues are even retested. Here are some helpful hints and ideas to get started:

• Keep things as simple and efficient as possible – no PowerPoint slides or agenda needed. All the demo requires is a meeting room, a laptop (or even better, a projector), a listing of defect fixes (along with high-level descriptions) and the essential team members.
• Include essential team members (ideally, those developers and testers associated with the functionality contained within the deployment) as often as possible. My teams have referred to this meeting in the past as a “DAT Session”. “DAT”, you may ask? Developer, Analyst, Tester. (Sometimes, it really is that simple.)
  • If applicable, why not include Business Analysts for clarification or feedback?
  • Even better, if you have an eager and co-located customer or client (i.e. Product Owner), why not solicit his or her feedback to save time? Non-complex scenarios or questions can be answered directly, saving even more time (and helping to avoid additional subsequent time-consuming meetings!)
  • Again, while the goal is to keep this as efficient a meeting as possible, at the same time, the possibilities really are endless. A forum for direct, face-to-face collaboration goes a long way and the team should take advantage of the opportunity.
  • Similar to another oft-practiced Agile concept – the “daily stand-up meeting” – try to “time box” the demo as much as possible, stick to topic and do not attempt to resolve issues. This is not a requirements meeting or a story-writing workshop. Yes, simple questions or clarification points can be agreed on and action taken. But if requirements are questioned or further clarification is needed, take it offline. The demo is not the forum for solving these issues.
  • Obviously, not every defect/fix needs to be demoed – usually, high-level demonstrations of simple functionality are adequate, and you’ll find they can uncover numerous issues before they are moved over to “ready to test”, which saves valuable time over the life of a project.

The Post-Deployment Demo – Team Acceptance
One final point – the first few iterations of a deployment demo can potentially have a risk of morphing into a “he said, she said” (or, more to point, “Testers” vs. “Developers”) conflict within the team. Employing this type of feedback session in practice poses a bit more risk to newly-formed teams who are unfamiliar with each other and still striving to progress through the “Forming and Storming” stage of “Tuckman’s Stages of Group Development”.

The reality is that in this forum, names are tied to tasks (in this case, names are tied to bugs) and people’s work is more times than not questioned (and sometimes indirectly criticized). Every effort should be made to avoid being overly critical when addressing issues when one person thinks something has been fixed while another person believes the functionality is still incorrect. Remember, it’s a team effort and everyone is in this together with a common goal of team and project success. I feel this simple yet valuable practice is a great tool to help get you there!

During the last thirty three years CC Pace has served our clients in a wide range of business and technology projects. While clients generally bring us in at the beginning of a project, others find a need for our expertise mid-stream. At times we have also been called into a project after considerable amounts of time and dollars have already been invested, only for the client to find the project nearing collapse and help is needed to try to turn the project around and salvage their hopes for ROI.

In the following article in the Harvard Business Review Donald Sull, Rebecca Homkes and Charles Sull have done an exceptional job of debunking the common myths behind why projects fail and the reality of what is required in order to ensure effective execution. Based on our experience, the Harvard Business Review has done a great job summarizing the key to project execution: successful coordination.

https://hbr.org/2015/03/why-strategy-execution-unravelsand-what-to-do-about-it

The role of a Product Owner in Scrum includes owning the backlog and preparing stories for sprints. As I work with product owners I remind them that not every item in the product backlog needs to be ready to develop.

Agile backlog and user story progression reminds me of the pyramids.

When we first start, we are at the base of the pyramid. Our customers have such big ideas we call them features. When we start to think more about the feature ideas, we create epics further defining what our customers will want. Those epic stories are still too big to fit into a sprint. So we continue to break them down into small pieces called stories.

As the stories get closer to being taken into a sprint, the story must be small and refined. A good Definition of Ready (DOR) will help us understand when stories are ready to move from the Product Backlog to the Sprint Backlog. The DOR helps the team agree on what must be included with the story in order for the dev/test folks to do their jobs. The basic story and acceptance criteria are required parts of the DOR. In addition, the team will add various items to the DOR list, e.g. wireframes, examples of formulas, and database excerpts.  Product owners should be working on stories they would like to see be developed within the next 2 – 3 sprints.

So in my example here, as stories percolate to the top of the pyramid, product owners review them with the team in grooming sessions. Then at sprint planning, the top stories are pulled out of the product backlog and become the sprint backlog.

The saying “just enough, just in time” helps keep product owners focused on ensuring the right stories get to the top of the pyramid, just in time for the team to work on.

For more information, check out Mike Cohn on the topic:https://www.scrumalliance.org/community/articles/2008/february/writing-the-product-backlog-just-enough-and-just-i

One of the basic Agile tenets that most people agree on – whether or not you’re an Agile enthusiast or supporter – is the value of early and continuous customer feedback. This early and often feedback is invaluable in helping software development projects quickly adapt to unexpected changes in customer demands and priorities, while concurrently minimizing risk and reducing ‘waste’ over the lifetime of a project.

Sprint Demo
In the Agile world, we traditionally view this customer feedback in the form of a formal product demonstration (i.e. sprint demo) which would occur during the closeout of a Sprint/Iteration. In short, the “team” – those building the software – presents features and functionality they’ve built in the current sprint to the “customer” – those who will be users or sellers of the product. Even though issues may be uncovered and discussed – usually resulting in action items for the following sprint – the ideal end result is both the team and the customer leaving the demo session (and in theory, closing the sprint) with a significant level of confidence in the current state and progress of the project. Sprint demos are subsequently repeated as an established norm over the project’s duration.

This simple, yet valuable Agile concept of working product demos can be expanded and applied effectively to other areas of software development projects:

• Why not take advantage of the proven benefits of product demos and actually apply them internally – within the actual development team – before the customer is even involved?
• Let’s also incorporate product demos more often – why wait two weeks (or sometimes even a month, depending on sprint duration)? We can add value to a software development project daily, if needed, without even involving the customer.

Expand the Benefit of Demos
One of the common practices where I have seen first-hand the effectiveness of product demos involves daily deployment of code into a testing or “QA” environment. Here’s the scenario:

• Testing uncovers five (5) “non-complex” defects (i.e. defects which were easily identified in testing – usually GUI-type defects including typos, navigation or flow issues, table alignments, etc.) which are submitted into a bug-tracking tool. Depending on the bug-tracking tool employed by the team, this process is sometimes quite tedious.
• Defects 1-5 are addressed by the development team and declared fixed (or “ready to test”) and these fixes are included in the latest deployment into a QA environment for retesting.
• Defects 1-5 are retested. Defects #1 and #2 are confirmed fixed and closed.
• But there is a problem – it’s discovered EARLY in retesting that Defects #3 and #4 are not actually fixed and additionally, the “fixes” have now resulted in two additional defects – #6 and #7. For purposes of explanation, these two additional defects were also easily identified early in the retesting process.
• At this point, Defects 3-4 need to be resubmitted, with new Defects – #6 and #7 – also added to the tracking tool.

Where are we at this point? In summary, all of this time and effort has essentially resulted in closing out one net defect, and we’ve essentially lost a day’s worth of work. Not to mention, developers are wasting time fixing and re-fixing bugs (and in many cases, becoming increasingly frustrated) and not contributing to the team’s true velocity. Simultaneously, testers are wasting time retesting and tracking easily identifiable defects, therefore increasing risk by minimizing the time they have to test more complex code and scenarios.

So there is our conundrum. In a nutshell, we’re wasting time and team members are unhappy. Check back for a follow-up post next week, which will provide a simple yet effective solution to this unfortunately all-too-common issue in many of today’s software development practices.