December 26th, 2012 | Katie McCroskey
Lessons learned at Agile Coaches Camp 2012
Agile Coaches Camp is something I look forward to every year: catching up with familiar faces and friends; hearing everyone’s horror stories, funny stories, accomplishments and successes, and most importantly – lessons learned over the year.
It is two days of education on a vast array of topics, from shaping team culture, Agile engineering practices, Scrum vs. Kanban, dealing with a difficult team member and complex Enterprise Agile issues. There is a topic of interest for everyone, that’s because the group picks the topics – there are no premeditated sessions and no prearranged speakers. Whatever happens at Agile Coaches camp was supposed to happen – the right people are there, and the conversations flow as they are meant to flow. I always leave feeling inspired.
Personally, my goal of Agile coaches camp was to explore Agile organizational culture and team environments. Well-built Agile teams operate seamlessly – with effectiveness and precision. Team dynamics are a crucial piece to the puzzle – there also must be respect and the willingness to help. The overall dominating perspective regarding Agile teams is that the whole team succeeds and fails as one. But here comes the challenge – how do you create that type of Agile team environment?
Through first-hand experience, great conversations at Agile Coaches Camp, and a few books read – I’ve come up with a few key factors that contribute to developing a strong Agile team.
First, the right people are important. It takes the right personalities, professional skills, individual drive, and willingness to work in a team environment. Another critical aspect of an Agile team is its never-ending drive to improve and status quo is never acceptable. This constant creation of change and continual learning in an Agile environment is typical. Stepping outside comfort zones is crucial for growth but isn’t always for everyone. It is this desire to change, grow and learn that builds great teams and experienced people.
Another important element to an Agile team is the ability to self-organize. Natural leaders emerge and there has to be enough trust, respect, and team buy-in for the team in order for this self-organization to occur in a productive direction. Simply, one weak link in the chain can disrupt the productivity of the unit and break the bond for the entire team.
Overall, the key to successful Agile teams is the overarching mindset that the team fails and succeeds as one unit. This concept can be applied to all shapes and varieties of an Agile team – from a team of developers/analysts/testers/designers to an entire organization that operates reflecting the Agile mindset.
April 27, 2011 | Jacob Stucky
The Agile Principles that impressed me most as a Software Developer
I spent the first several years of my career as a software developer in a non-agile environment. We didn’t purposefully follow any particular software design model, but we ended up getting fairly close to a waterfall approach. We would go through the motions of creating both requirements and design documents, but each phase would never seem to truly finish as we were forced to start later phases early due to time and budget constraints.
Without a clear development model, a developer might end up taking the mostly finished requirements document, a half-finished design document, and the memory of a conversation on how the system was supposed to work and spend a few months in development. The developer could easily spend months lost in the code without the support of another set of eyes to look at the code and assist with problems, or to keep him honest (i.e. not taking shortcuts, writing quality code).
Of course, developers always have deadlines, and in my experience in non-agile environments, it’s no surprise to have to put in long hours in order to meet the deadline and get the software released into a test environment. This was often the first time someone other than the developer would see the project; the extent of the testing being when the developer ‘tried it’ as a part of building the feature.
Hours of phone conferences, bug lists that are dozens of items long, and more months of hot fixes and changes would follow, and might continue well after the production installation. You hope to avoid, but are not surprised by arguments over budget, timeline, and what features were or were not included in the ‘approved’ requirements and design documents.
The result of projects such as these is that a single developer ends up ‘owning’ each project or large feature. If that developer ever leaves the company, there is a mad scramble to do a knowledge transfer to another developer for maintenance or new features. Heaven forbid the elusive ‘version 2’ ever gets approved and the new developer actually needs to have a full understanding of the system or feature.
When I joined Thycotic I was introduced to several agile principles. Here are the ones that made the most impact on me as a developer:
Test driven development
Test Driven Development, or TDD, was probably the largest and most difficult adjustment I had to make. This was not because I was ideologically against the goals or ideas of TDD, but because it requires an adjustment of how the developer thinks. For the eight years I had been writing software I’d always had a full plan in mind of how each piece of functionality would be implemented and would often stub out, or even fully write, methods that I would later need.
With TDD you do not work ahead in that way. You start with a single failing test and only write the code that is necessary for that test to pass. This is followed by another failing test, and the pattern continues, with a step to look for refactoring opportunities whenever you have full green tests. This refactoring is safe because you can simply rerun your test to confirm the code still works. The benefit of this process is threefold. One, you have not wasted time writing code that is not needed. Two, every bit of code is written in order to fix a failing test, giving you full test coverage and confidence that if the code breaks at any point, your tests will be able to inform you. Three, with properly named tests, by the time the feature is complete your tests serve as full code documentation for how the feature works and what results should be expected.
Surprisingly, at least for me, the transition to programming with a pair was not a difficult adjustment at all. Even in my previous jobs there were times when someone was stuck working on a particularly difficult section of logic, and having two people look at the problem together helped solve the problem in much less time. Pair Programming gives you that benefit at all times. Not only does having a second developer working with you help when solving a complex issue, you and your pair also work together to keep the other focused. A pair working together is also more likely to follow best programming standards than an individual working alone due to the presence of peer accountability.
Working with smaller, manageable increments of time and a solidly defined amount of work is simply amazing. There really isn’t much more I can say about it. Instead of looking at a daunting project that will take months to finish, with no tangible goals in sight, everything is broken down into two-week increments.
The progress is tracked daily and it is easy to see with a glance how you are doing. There is rarely an impending sense of ‘This is never going to get done’ because you discuss and agree to what you can finish in the two week period. Everything else is outside the scope of the sprint, and thus outside the scope of concern for the time being. Of course, you revisit that additional work in the next planning meeting, but when you sit down to actually program, it is not hanging over your heads.
The sprint planning process is the most difficult part of a sprint because it means making sure that you can finish what you committed to, while at the same time not under committing. However, as teams gain experience, the process improves and as a result, so does the ability to plan accurately.
Verifies and QA process
For all but the simplest story there is a set of written “verifies.” For example, “Verify that there is an edit button on the page.” These verifies serve as a checklist for the QA process. The story isn’t considered complete until the entire list of verifies for that story are tested with a release build and signed off by the pair that performed the QA. Because of this guided and focused QA testing we have much more confidence in every story we complete, rather than if we had simply ‘tried it’ while developing, or after a fresh install did some ‘clicking around.’
I feel like I really hit the ground running at Thycotic. The agile techniques meshed well with my programming goals, and I immediately saw the benefit in this programming style. Moving entire teams to this style of programming would likely take effort, since it is a change in how programmers, management and clients interact, and it requires serious dedication from both programmers and all levels of management. But through this focus, I have also seen the benefit of more consistent results, better accountability, and a better quality product.
April 14, 2011 | David Cooksey
The Agile Virtue of Transparency
Transparency runs contrary to human nature. We all want to look good, however, the greatest programmer in the world will still cause bugs. Few designs are so prescient that they never require updating. When mistakes or design flaws are discovered, it’s natural to downplay, hide, excuse, or otherwise mitigate the negative effect these mistakes have upon our reputation.
Unfortunately, this human tendency can cause many problems. Bugs can remain unfixed and architectural flaws unresolved. In order for our code and processes to be useful, our mistakes need to be brought to light and corrected. This is precisely why transparency is so valuable, and also so difficult. A team or organization must be structured in such a way that mistakes are corrected while simultaneously encouraging people to own up to their mistakes.
Naturally, common sense applies. There is no need for every developer to constantly inform the team every time they make a typo or cause a test to fail locally. Transparency does not mean that every individual detail should be published to everyone up and down the chain. No one can absorb all of that data, and the sheer mass of data would actually discourage transparency because it would be extremely hard to find the data points that are relevant. A problem or potential problem should be brought to the attention of the people who can resolve the problem, and those who should be notified of it as soon as possible.
A friend told me a story recently that does an excellent job of illustrating the value of transparency between levels. His company had decided that it was time to create a new website. Their website was functional, but could use a facelift. Also, there was a lot of business logic in the database which could possibly be pulled out into a services layer. The team was hired and they got to work. A year later, the new website had less functionality than the original website. Content management required business analysts to open and compile multiple Visual Studio solutions. A change to a stored procedure parameter required compiling more than 12 independent solutions—and no business logic had been pulled out of the database.
This occurred because the people asking for the new site had no view whatsoever into what it was going to be. There was no involved product owner. There were no intermediate demos that evaluated progress or architecture. There were no intermediate releases to gather feedback. As a result, a year’s worth of time and considerable funds were wasted.
This is an extreme example, but it shows very clearly why transparency is such a valuable virtue for an organization to have. Opaqueness makes it far too easy to hide flaws, which can dramatically increase cost to the company.
So, how do we encourage transparency within an organization? First, lead by example. If a manager never admits to a mistake, chances are the people working for that manager will never admit to mistakes either. Secondly, avoid mockery. Scorn, ridicule, and condescension train people to protect themselves emotionally by hiding their mistakes. Every developer will cause bugs and make poor design decisions from time to time. Third, extend a helping hand. The field of development is so large that no one is an expert in everything. Sometimes a bug or unusual design decision is caused by incomplete understanding of part of the specific system or the underlying programming concept. A team effort to fix the bug, if it is significant, can help create a sense of community and avoid the blame game.
There is no doubt that transparency is difficult to achieve and maintain. However, if you want to develop products that meet the needs of your users in a work environment where people can focus on their work instead of appearances, it is essential.
July 14th 2010 | Jimmy Bosse
Agile, Scrum: Always Require the Retrospective
If you’re thinking about bringing Agile, Scrum, etc. into your development organization, I have one important piece of advice: always require, and never stop doing retrospectives.
I don’t care if your team is made up of brilliant developers who resist a new process, or project managers loathe to try something new. In my opinion, the retrospective is the single most important element of the Agile process. Implement it early, and keep it even if you scrap everything else.
The power of the retrospective to a development team is immediate and relevant change. The practice of developing software is littered with beleaguered development teams, exhausted from consistently delivering the impossible and getting very little recognition in return. When they express a desire to change things that effect their daily life but don’t provide immediate business value, their requests fall on deaf ears.
In Agile development, the team is paramount and their concerns are of great importance. The retrospective is the vehicle for improvement for both the team and the software it produces. When you provide a team with a forum to express their concerns, and commit to implementing their recommendations, the result is a motivated, productive team. As a developer, I always get an opportunity to engage in a dialog with my team to decide if my concerns are valid. Not every request or suggestion will be granted, but knowing my opinion is being seriously considered makes this easier to accept.
Without the retrospective, my recommendations and those of my team become a morale sinkhole, demoralizing the team and compromising the quality of the software we deliver. Issues and bugs become a game of CYA and everyone points fingers at everyone else. But in an open, collaborative environment the team as a whole takes responsibility for issues and bugs, responds to them quickly, and has an opportunity to discuss how to keep them from happening in the future.
The retrospective is a time for the team to discuss what is working and what is broken; decide what incremental change is most important; and commit to fixing that one thing. At the next retrospective the team evaluates whether that change made things better or worse. Surprisingly, sometimes an item that was considered an improvement a few month earlier might now be identified as broken. It doesn’t matter if it worked well before—if the team decides it’s not working, they scrap it and keep on moving. Who knows, it might just be back again in another three months, but I am content in the knowledge that every two weeks (or whatever your iteration cycle might be) I will get the chance to make things better.
That makes me a happy developer, and happy developers make better software.
If you have any questions about this series of posts or about DevConnections, feel free to send me an email (jimmy.bosseATthycotic.com) or message me on Twitter @jimmybosse.
April 1st | 2010
I recently read a book by Esther Derby and Diana Larsen titled Agile Retrospectives. When I first started skimming through the book I was rather skeptical (an activity titled Mad, Sad, or Glad? Right…) However, when I actually sat down and read through it I realized that the authors had a lot of good information to present. They also understood the disinclination of engineers to engage in activities that seem silly.
Agile Retrospectives focuses on iteration or release retrospectives, which primarily involve the development team. As such, there are a few goals that the various steps and activities presented in the book are designed to satisfy.
- Collect the viewpoints of everyone on the team, not just the most vocal members.
- Group the collected information to see what the team as a whole thinks.
- Come up with clear goals to improve based on the information collected.
This deceptively simple list of tasks includes what I believe to be the most challenging element of any retrospective meeting; keeping all team members engaged. If a few vocal members dominate the discussion, there is no guarantee that their stated issues or suggestions are identical with what the rest of the team thinks. This can result in decisions based on a vocal minority, never a good thing in a team environment.
Agile Retrospectives defines five stages within the retrospective .
- Set the Stage
- Gather Data
- Generate Insights
- Decide What to Do
- Close the Retrospectives
Each stage has a number of possible activities listed that are intended to keep all team members engaged and balance the results from each member against the team as a whole.
Our retrospectives occur about every two weeks, and are relatively informal in format. Process hiccups or any significant roadblocks are discussed and incremental suggestions made for the next iteration. We try to keep any changes small in order to reduce the cost of adjusting processes and reduce risk.
I’m interested in hearing about how other teams handle retrospectives or project post-mortems. Have you developed your own activities? How useful do you feel the activities or retrospectives in general are? How do you keep everyone engaged?
February 4th | 2009
The Benefits of Pair Programming
The Agile practice of Pair Programming is one of the more controversial development techniques within the software development community. The controversy lies in the question of how two programmers working together on the same code can be more productive than the same two programmers writing code individually. The determining factor in answering this question is simple – more lines of code do not equal more productive software development.
Case studies have been conducted, the experts have weighed in, and the results are unequivocal: the benefits of Pair Programming can result in significant advantages for an organization developing software.
The success or failure of software is dependent on its quality, and Pair Programming directly improves quality in numerous ways. When two developers work together design pattern quality improves as the pair develops short, simple, and easy to maintain code with fewer bugs. Bugs are a major quality concern in software development; with two sets of eyes writing the code, more mistakes are caught, thereby decreasing the cost of development. Bugs found late in the development process are often costly to fix. Finding software defects early prevents and helps deter difficult problems down the road. Complexity often arises in programming, and two minds working to solve a problem together can see more options and draw conclusions more quickly than one.
Teams implementing Pair Programming also experience the benefits of increased team morale, worker discipline, and improved time management. Individuals on the team put more effort into writing good code, creating an atmosphere of collective code ownership.
Our team has been practicing Pair Programming for years, so I set out to get some input from them. Thycotic team programmer, Bryant Smith, has been Pair Programming daily for over five years. Bryant commented “The code’s intention is clearer, it self-documents. What might be clear to me is not necessarily clear to others; assumptions are uncovered and more clearly stated. This is true with the unit test code as well as test coverage. When my pair is coding I often think outside the box about ‘what if’ scenarios. This extra test coverage further documents the code’s intention.”
Another team lead member, Tucker, thought “A major benefit of Paired Programming is knowledge sharing. It breaks down code complexity across the dev team and quickly brings new people up to speed.” Tucker is currently working with 3 other developers—forming two programming pairs every day.
Risk for management is also decreased as knowledge is spread around the team, pairs are rotated, and team members come and go. The benefits of Pair Programming to the development team, management, and the organization are significant as the software development process proves to be on time, within budget, and seemingly effortless for a Pair Programming team.
June 25th 2009 | PouyaYousefi
Pair Programming in the Time of Swine Flu
I am not a doctor. Nor do I claim to have any medical knowledge other than what I pick up from watching House. I am an “Agile Expert”, a “Test Driven Developer” and a “Pair Programmer”. That last existential statement has faced new challenges with the recent media scare and the possible pending spread of global pandemics such as the H1N1 virus, more commonly known as the “swine flu”.
Inherent to pair programming is the need for close proximity to another person. Although in the past our team has conducted remote pairing with some success, our day to day development requires that two programmers need to sit across from each other at the same pairing station sometimes for several days. Now it does not take a genius to see that this situation would be ideal for the passing and spread of communicable diseases.
Our team has taken many measures to combat the possibility of our team members getting sick. We have alcohol-based hand sanitizers at every pair station, provide alcohol wipes for cleaning the keyboards and pairing areas, and allow for working from home. We hope these measures reduce the likelihood of catching or spreading any illnesses but I believe that an inherent mental shift in thinking needs to occur in order for any measure to really work. That shift in thinking is this: “Do not come to work until you are 100% over your illness.”
I am guilty of coming to work when I feel less than stellar in order to preserve time for an upcoming vacation. Sometimes the urge to get back to work to help the team can sometimes hurt the team instead. Pushing to get back to work when your body is not at 100% can prolong your illness, make you susceptible to other illnesses, and expose others.
Kent Beck, one of the leading minds on Agile methodologies, and the author of eXtreme Programming Explained explains that one of the values of XP is respect. He states that respect is the fundamental value that binds the team and drives the project towards a unified goal. Taking care of yourself should be as important as looking out for your team. The next time you “suck it up” and drag yourself to work because you think it makes you a team player, stop and think about whether or not your staying home might be better for the team in the long run.