Putting the “Dev” in DevOps

written by: Chris Knotts on September 30th, 2014

It’s been a good five years since the #DevOps hashtag showed up on Twitter and IT operations teams everywhere started talking about it. But with cloud infrastructure exploding and applications teams growing ever more aware of the capabilities and environments available for deployment and integration, we are definitely hearing more interest in DevOps from our customer base of developers and application teams. The DevOps mentality and the associated skills are becoming important areas of interest for them as well. DevOps isn’t just for ops anymore…and it wasn’t ever supposed to be, was it?

There are a few key factors that are beginning to drive real engagement from the Dev side of the house:

  1. The agile mentality has grown widespread and influential, beginning to reach maturity in the marketplace and the workforce. An agile approach to development is the natural analog to a continuous deployment mentality on the operations side of the house. But perhaps more importantly, agile development teams should understand that they must integrate tools and practices into their project efforts which identify important stakeholders across every area of the IT shop, especially those associated with deploying their applications. This overlap is more than just application people getting interested in DevOps – it is DevOps.
  2. Achieving an end goal as a group is not about technology; it’s about people. It can be tough for both developers and operations people to embrace all the change that’s required to really put this shift in thinking into action. However, it’s a rising sense with everyone you talk to who is involved in IT projects and IT operations. The widespread agile coaching that is going on with application teams everywhere is again a contributing factor here. A foundation of team efficiency and capability, combined with a philosophy which views everything through the lens of successful achievement of a result – it’s not easy to disseminate that mentality across everybody in the IT shop. But thanks to DevOps and Agile (and remember…before there was DevOps there were proto-DNA conversations around Agile Infrastructure), necessitated by the cloud and a wealth of new tools that allow exponential gains in efficiency, we have some real driving force powering DevOps on the application side.
  3. Code, code and more code. Software is eating the world and IT is increasingly a recipe of various abstractions. Whether they serve the purpose of a service oriented piece of software, or an abstracted piece of hardware, there’s an awful lot of programming language being spoken. The rise of the cloud has meant more scripting, more infrastructure as code, and more creative possibilities when it comes to IT frameworks. This seems to be attracting the interest of a growing number of developers. On the flip side, I’ve talked to more than a few system administrators and IT operations folks who seem to allude to a nervous population of operations people who wonder if the professional code writers over in Dev are going to gradually supplant them.

Certainly there is more to the picture than just these three ingredients, but these would be three of the top dynamics. And if we do see a widespread shift from Dev toward adopting a DevOps type way of working, then it could signal the mainstream absorption of DevOps as Standard Operating Procedure that many feel is imminent.


Agile Team Capacity Estimating

written by: Kaete Piccirilli on September 24th, 2014

This content was originally posted on cprime.com.

When working on a project and looking at project management, discussions tend to focus on understanding the requirements and creating the schedule. This is important, but it is also important to understand the work of a project done by the people working on the project.  We need to understand how much work they can do in order to understand the scope that can be delivered in a schedule.

The common approach to scheduling for plan-driven projects is to define tasks and their dependencies (what needs to get done first), estimate the effort per task, assign the individuals to those tasks while performing resource leveling and produce a schedule for the project. However, the Agile approach focuses on the teams and not the individuals. Agile assumes that the Team is a group of people who have the combination of skills required to do the project work. The team then self-organizes to identify tasks, assigns owners to those tasks and they do the work as quickly as possible. Because of the team orientation, resource calculations focus on how much work can be completed by the team rather than the individual. Performing the analysis is much smaller for an Agile project than for a typical plan-driven project.

With Agile Teams, we treat them as equivalent for estimating the team’s total capacity to get work done during a specific time. We know that each person does different types of work and each person has a different skill set, but for estimating purposes, we treat them as equivalent.

In Agile Projects, we typically do the “Task Breakdown” and break down the work of implementing and validating requirements into a set of tasks to be completed with each requirement specification, or what we call the “User Story.” Most Agile projects estimate in person-hours, therefore, we need to determine how many person hours of work a team can perform in a particular Sprint or Release (a determined period of time).  A Person-Hour is the basic unit of effort representing one hour’s work by one person. This unit is not related directly to duration. For example, two people who spend a total of 4 hours each doing some kind of work expend eight person-hours of effort, regardless if they do all of the work in one day or in increments across several days.

To determine effective capacity, we will use a resource model and consider the following factors: number of workdays in the period, number of team members, known meetings or activities which involve the whole team, planned time off for each member during the period. The approach is simply put into a spreadsheet.

Team Member % Available Hrs Off Hours




















Person Days Available


Net Team Resources


Team Hours




  1. Number of Workdays in the Period X 8 hours per day = Total Work Hours in the period
  2. Total Work Hours – total time allotted for team meetings = Net Work Hours and this should be smaller than Total Work Hours
  3. Get availability and time off for each person and do this calculation:
    1. Net Work Hours – Time Off then multiply by the result to get this person’s individual capacity.
  4. Add up the individual capacities to get Team Capacity in person hours and then divide by eight to get the capacity in person-days.
  5. Divide Team Capacity in hours to get Net Team Resources which is the effective number of Full-Time People on the Agile Team.

In my example, I’ve noted that everyone has 20% time spent in meetings and the rest is available for work. Tegan is an Intern working only 20 hours a week therefore she has 20 hours off per week.  One of the interesting things to note is that when you calculate hours this way, you have a more visual picture to see how meetings can reduce the ability to complete work and be efficient. The Team shown here has 4.5 full time equivalents, but only 3.1 effective full time people.

Now some tasks require specialized skills. For example, Joseph is the only Graphic Designer on the team and he has some specific .php skills that only he can do for the team. Some might consider this process of hours planning meaningless because he’s the only one who can do particular types of work. However, most of the time this planning will work because in task planning there are specialized and general tasks and the general tasks can be done by more than one person. Typically, the approach is effective as long as the specialized tasks don’t dominate over the general tasks. There are always exceptions and when that happens, a more complicated analysis may be needed.

The Agile approach to estimating team velocity over a period of time is a team-oriented approach with a team oriented analysis and it is usually effective with an appropriate split of general and specialized tasks.

Want to learn more? Register for our Agile Boot Camp and get an immersive, hands-on training course that teaches you everything you need to know about implementing Agile in your team.


Web Seminar Recap: Business Book Report- The Black Swan: The Impact of the Highly Improbable

written by: Tegan Smith on September 19th, 2014

Each month we pick a valuable, substantive business book we think will benefit the professionals we serve. Some are new; some are classics. Either way, we do the reading, and then use one of our free web seminars to deliver a one-hour “book report.” This month’s book pick is The Black Swan: The Impact of the Highly Improbable by Nassim Nicholas Taleb.

Taleb has written a book that explains how the business world works now more than ever. It’s a world of fast-paced, unpredictable events that are hard to keep up with and even harder to predict. If you are a professional who struggles to cope with change or find ways to deliver value quickly enough to respond to the market, this is a must-read.
Taleb put his finger on the dynamics of a world where luck, evolution, unpredictability, and response time all converge to make it seemingly impossible to navigate a market landscape that just moves too fast. However, he also explains how navigation is possible for those who understand the underlying drivers, and how it’s actually possible to stay nimble and alert, ready to respond when events occur that are impossible to predict – events Taleb calls “Black Swans.”

This one hour Business Book Report seminar on The Black Swan: The Impact of the Highly Improbable was held by Chris Knotts on Tuesday, September 16th, 2014. If you missed this great seminar, catch up by downloading the recording and slides here!


Frequently Asked Questions: Transitioning from Waterfall to Agile

written by: Tom McGraw on September 16th, 2014

Following the most recent “Agile, Iterative and Waterfall” web seminar, presenter Tom McGraw addressed some of the FAQ’s that may arise while a team is transitioning from Agile to Waterfall. With this transition becoming a popular trend and many companies following suit, we thought that these questions and their answers were too good not to share!

The complete seminar slides and recording are available for free download here. For similar seminar topics visit our seminar archives page.

FAQ: Agile to Waterfall by Tom McGraw

Our organization is beginning to move to a more agile practice.  Many people seem to be of the impression that agile does not have or require documentation. Can you describe the role/type(s) of documentation are best in an agile environment?

Although Agile values “Working software over comprehensive documentation”, it doesn’t mean there should be no documentation at all.  Oftentimes, having the right Agile tool for your process can solve this problem and retain the necessary information.  With that said, if the documentation has a customer, or provides value to you and your team, it should not be discarded entirely.  Documentation that is never reviewed in the future, has no value, and has no ‘end customer’ is documentation that should be discarded.  There is a helpful, brief video from one of our Agile SME’s that may provide additional insights on this topic:

Are sprints a combination of random enhancements as well as iterations of a larger requirement?

Sprints and iterations in most cases are synonymous.  Organizations can adopt their own Agile processes which in some cases can differentiate the two based on certain criteria (i.e., multiple sprints can be a part of an iteration).   The two terms really arose through the formalizations of specific Agile flavors.  As an example, Scrum names the increments in development ‘sprints’.

Can you explain epic story vs. user story? What flags a story as epic?

Epic stories can be used differently and understood differently across various Agile teams.  In short, an epic story is more than likely some large user story that may not be able to be implemented without being broken down into smaller pieces.  There are no true widely-accepted defining criteria for what would be considered a ‘user story’ versus an ‘epic’.

What is typically outlined in a client’s contract if the development work is using an Agile method?

There’s limited information at this point, because of the few contracts written for Agile projects.  Most organizations do not bid contracts using Agile terms, and they’ll even translate into hours instead of the story points in some cases.  Few RFP’s require responses with Agile terms, and it may be up to you to determine based on the scope of the project outlined if an Agile approach is the best approach.  With all of that said, there is an increasing number of requests that include a requirement for holding some sort of relevant Agile certification (CSM, ACP, etc.)

Can changes within the current iteration be acceptable too?

This can be difficult to answer because it is highly dependent on your current processes.  In many cases sprints and iterations are synonymous, and in some environments, sprints may make up a larger iteration.  If there are changes mid-iteration, I’d be highly cautious of the impact that can have on other planned story points to be completed in the same iteration.  If the right controls are in place and there is truly a need to make a change during the current iteration it can be acceptable if managed appropriately.

I missed the first 3 identifiers of agility, can you restate those

Sure, the first three identifiers of Agility, as discussed in the presentation are “Frequent Deliverables”, “Adaptability to Changing Requirements”, “Shared Responsibility”.  More information for each of these characteristics of Agile teams is on the slides, which should have been provided to you via email after the presentation.

Can you point us to some online free resources to read through the best practice to follow for Agile project.

Well, I’ll start with ours at ASPE.

A number of Agile-related white papers and documents overviewing practical implementations can be downloaded on our free resources page: ASPE-SDLC Free Resources

Now, if you are a member of an Agile community (i.e., Agile Alliance, Scrum Alliance, PMI), those organizations typically provide countless resources shared amongst the community.

PMI provides a ‘Reference Materials List’, which lists many of the well-recognized readings and resources available pertaining to Agile: Reference Materials for PMI Agile Certified Practitioner (PMI-ACP)® Examination


How Agile Project Management Can Remedy Your Project Failure

written by: Christie Marsh on September 15th, 2014

With large scale projects, there is a lot on the line and a lot that can go wrong. Often these projects are delayed or not delivered as they were promised. This is a common occurrence within government organizations due to their regulations, but can affect any industry.

No team wants to be underperforming. We all want project success, not failure. With agile development, you are able to adjust the outcome of the product throughout its creation, preventing the sudden bugs and problems when the product is released months or even years down the line.

Using agile project management, large projects are broken down into smaller phases that are continuously addressed. Teams complete a small amount of requirements, design, coding, integration, testing and delivery of working code each week. This allows for things like scalability and user testing to be integrated earlier in the process and corrections can be made to problems as they occur. The time and money spent on rework will therefore be minimal and give your team a better chance of meeting budget and deadlines.

As projects become more complex, they will benefit more and more from moving towards agile project management. With the right process and training, Agile adoption could be what makes your project succeed.


Q&A with ICAgile Expert, Kelly Thoma

written by: JT Moore on September 11th, 2014








Q: How did you get started with Agile?

I started my Agile journey in 2011 when I was assigned as a business analyst to the first pilot project at my company that was going to use the Agile mindset and advanced practices in developing software. We were taking a transformational approach of “Being Agile”, first applying the mindset, and not just “Doing Agile” practices. I was hooked as soon as the instructor, Dr. Ahmed Sidky, opened his mouth! I was captivated by Agility and that experience has changed my career. I gravitated towards a specialty in Agile training, coaching and facilitation. As a business analyst on that first pilot, I participated in four incremental deliveries for the product and then was asked to join the company’s Agile Transformation Initiative. And I’ve “Been Agile” ever since. 

Q: You have a rather unique title: Agile Coach on the Agile Operations team. What is your day-to-day like?

A typical day for me consists of delivering Agile training to employees across our enterprise. So far, I’ve trained over 600 employees in the Agile mindset and practices associated to incremental development and iterative delivery. In addition to training, I also have responsibilities of participating in strategic discussions regarding the rollout, or transformation of the enterprise, from applying a traditional waterfall approach to an Agile iterative approach. I also spend a great deal of time coaching teams that are new to Agile in applying practices such as Chartering, Iteration Planning, Software Demonstrations, Retrospectives, Backlog Grooming, User Stories, Estimation, etc…

Q: What challenges do you face with scaling Agile?

When transforming a large enterprise, we have to remember we are also transforming people and a deep-routed culture. We have to remember to employ good change management concepts and recognize that we are asking for individuals to change, and that everyone experiences change differently. We are asking people that are experts at their jobs, and have probably been for a long time, to do their job differently. With that, we have to be prepared for resistance and managing how different people will react to change, from despair, fear, hostility and even happiness (as in my case) until we gradual start moving forward with acceptance.

Q: Why did you seek ICAgile certification?

I’m not the type of person that just collects certifications to have them so it looks good on my resume. I think that most anybody can study for and pass a test, and that doesn’t mean he/she can actually demonstrate the necessary skills required to be an effective coach. Let’s face it, coaching is about people, not just projects and passing a standardized test doesn’t tell you anything about your people skills. ICAgile certification is competency based, which means you have to prove in front of a panel of industry leaders that you actually have the goods to be an effective coach. I feel that in addition to the knowledge, I now have industry recognized credibility.

Q: How was the ICP certification process/experience?

When I started on my journey, I didn’t really know where I was headed. My first stop was becoming an ICAgile Certified Professional (ICP) after taking an Agile Fundamentals class. When I joined my company’s Agile transformation initiative, the next stop was becoming an ICAgile Certified Professional in Agile Team Facilitation (ICP-AFT) and then becoming an ICAgile Certified Professional in Agile Coaching (ICP-ACC), after completing both the associated course learning objectives, respectively. I pursued all this training and certification to become a more effective Agile coach and assist my company, teams and individuals through an Agile transformation. At this point, I still wasn’t entirely sure where my Agile journey was taking me.

Q: What caused you to seek further certification and pursue ICAgile Expert-level certification?

I’ve never been accredited or certified in anything before.  This opportunity is unlike any I’ve come across.  When ICAgile finalized their process for the Expert-level (competency-based) certification I knew it was meant for me. I started to read about the qualifications and study the competency rubric and said, “Hey I can do this. It’s a challenge, and I’m up for it!”

Q: Which track of the ICP certification did you take? And why?

I took the Agile Coaching track. I have always wanted to help people. It’s been my dream; in my youth, I even contemplated the medical field, and have discovered I have fulfilled my dream by helping others in the IT field instead.  The niche I’ve found within ICAgile allows me to give back to the community.  ICAgile has given me the opportunity and credentials to fulfill my dream of helping others.

 Q: How was the preparation for the Expert-level assessment?

My own personality forces me to be over prepared, but it is a serious process and should be taken as such. In addition to the required training and coaching experience, I had to submit a 10-minute video demonstrating my facilitation skills. Along with the video, I had to provide time markers from the video describing what facilitation techniques I was demonstrating. I must have watched that video a hundred times to get the markers just right! I also had to submit three references of people that I had coached, with at least one of them being new to Agile. I was also required to submit facilitation guides and any other documentation that would demonstrate my thought process in preparing for facilitating or coaching a team.

Q: How was the ICE-AC Gate review process?

After submitting my application with all the aforementioned documentation, I had to sit before a panel of industry experts for a 2-hour interview/gate review. I was extremely nervous, and was soon feeling relaxed after a quick five minute round of introductions. Next, the panel watched my video live which was followed by a short Q&A. I was glad when that was over! Next, I did a 10-minute coaching role play, followed by a 10-minute mentoring role play. Boy was I glad when that was over! This was followed by another round of general Q&A. Lyssa Adkins had some really tough questions.  I’m glad I prepared as I did because I kept thinking “Boy, I don’t want to go through this again!” The panel then deliberated for 35 minutes while I stepped away and prayed that I would pass. Upon rejoining the panel, I was elated to find out I did pass. Even though I passed, I was really appreciative when the panel gave me great feedback intended to stretch me a bit and make me an even better coach.

Q: How do you think the Expert-level certification is going to help you at work?

Several of my colleagues will be taking the Coaching Agile Teams class this month. I hope I can help them prepare, study and also pass on the first try! As more people become involved with ICAgile, our transformation will deepen.  It will give our program additional visibility, and people will see the results. This feels like just the beginning for me.  It’s all about the journey and not the destination. I’m 100% confident that I want to stay on the path and keep learning.

Q: Any advice for anyone considering ICAgile certification?

Don’t take it lightly. It’s a serious process.  Let it be serious.  Be open to the possibility that ICAgile will change your life.  For me it is the culmination of everything I’ve been looking for.  

Q: I heard you are the first woman to become an ICAgile Expert. What are your thoughts about women in Agile or software development in general?

I don’t really think in terms of male versus female or that I’m at some disadvantage or a victim because I’m a woman. It never crosses my mind when I enter a room to coach or facilitate that I will be treated any differently because I’m a woman. My attitude is, “This is who I am and this is what I do.” In fact, I think there can be some very strong advantages to being a woman when it comes to Agile coaching. I certainly feel I can tap into my emotional, sympathetic, almost maternal instincts when it comes to helping others.

I’m inspired by this quote from Lysaa Adkins in her book, Coaching Agile Teams, “A friend loves you just the way you are. A coach loves you too much to let you stay that way.” Being a coach takes courage.  The change is about helping someone become who they’re really capable of being, and it comes about by how you cultivate relationships.  When someone calls and asks for my input, they begin to initiate the acceleration of their own process.  I don’t need to do anything for them.  It’s about triggering a different view of the world.

Q: Any advice for women in Agile?

Over the past 20+ years, I’ve had some great female role models in the IT industry. I don’t think we are at any disadvantage, and I hope to see the trend of women in Agile continue to increase. I may be the first, but I’m certainly not the last. 


Web Seminar Recap: Achieving Scrum Mastery – A 1-Hour Coaching Clinic

written by: Tegan Smith on September 11th, 2014

On the surface Scrum and agile practices seem simple — don’t they? At heart, they are. In fact, “doing Agile” is relatively straightforward. So why are so many organizations struggling to effectively implement agility?

There are several culprits. During this hour, ASPE expert and Certified Scrum Coach Bob Galen will address some of these impediments, and take attendees Q and A in a free one-hour coaching clinic. Attendees discussed and learned about:
- Estimation
- Release Planning
- Agile at Scale
- Done-ness
- Investing in Technical Debt
- Engaging Leadership
- Enhancing Transparency
- Effective User Stories
- Team Buy-in
- MVPs
- Distributed Teams

If you’re struggling with various aspects of agility, getting the return on your agile investment or stuck “going at it alone,” with no guide through tough Scrum challenges, this free, one-hour coaching session with a pragmatic and highly experienced agile practitioner is for you! Attendees created the Product Backlog for this workshop, and brought questions and challenges to see what “being Agile” looks like in the wild.
This one hour seminar, Achieving Scrum Mastery – A 1-Hour Coaching Clinic, was held on Thursday, September 4th by Chris Knotts and Bob Galen. If you missed this seminar you can catch up by downloading the slides and recording here!