And we are back for day two of the STP Online summit for "Agile Transitions".
Today's focus is, again, meant to help give some "How's" to play with, and today's panel will be giving us three somewhat familiar faces to see and listen to (well, I'm familiar with the three; your mileage may vary, but if you are not familiar with Lisa Crispin, Selena Delesie and Lanette Creamer... you need to get out more :) ).
The first talk for today (Session 4) is from Lisa Crispin, and it's Lisa's take on the topic of Successful Agile Test Automation. For most of us, we probably have a mixed bag when it comes to getting tests automated. There are a number of obstacles. In my world, we have unit tests and TDD level tests, and then we have my area that's mostly external facing tests (that's by design, but it does mean that what I look at is not entirely the same as what our development team looks at). Additionally, in many environments, we struggle with the idea of a sustainable pace. We face a real danger of things being back ended because we're often rushed, and because of that, there's just so much to do and so little time to do it. This is technical debt building up, and it ultimately saps our energy, the same way that financial debt saps our energy.
One area that we miss is that test code is often treated as second class. Out tests are as vital to our success as our production code, so it's important that we consider our test code on the same level, employing the same level of dedication, rigor and focus (this is why I have a github repository for my tests and frequently make changes and updates). We also have a bit of a challenge when we "own the automation" piece of the puzzle. I can vouch for the fact that we do spend a lot of time doing coding, debugging code, manually testing to confirm our scripts, and other maintenance issues. For a Lone Tester like me, that can often mean I have to choose whether or not I'm focusing on automation or actual testing. For us loners, there's no way to do both at the same time.
Testers do a pretty good job when it comes to identifying areas to be automated; exploration, troubleshooting, etc. For me, that part is not the problem. It's the mechanics of the automation that often causes me headaches. I was lucky in that I got a jump start with one of our developers where we paired for several weeks to get me up and over that initial hump. Still, I spend a fair amount of time tweaking the details so that they do what I really want them to do.
Our developers have a good handle on Continuous Integration, and my goal is to make it so that my tests can get the same treatment. Once I have my tests running in a Continuous Testing format, then I'll know I'm where I need to be :). Another important aspect is that, just as developers re-factor source code, we need to be ready and able to re-factor our test code. It's important to have a good focus on what we want to test first, then incorporate that into the way that the code is written. Experiment and learn, and see if new ideas come together. Another recommendation... under-commit. Don't slack, but really understand what you can really do, and then focus on the work that can be realistically done. Remember, testing is not a "phase"; it's always happening. Oh, and remember, "friends don't let friends Record and Playback" (with thanks to Claire Moss for that rather pithy comment :) ).
The second talk for today (Session 5) is from Selena Delesie and the topic is Culture & Inter-Focus Area Interactions. Let's face it, Agile is a great methodology and set of principles, but we all have to work with real people in a real world that's sticky, messy and hardly every working exactly as planned. We're just going to go and "Do Agile", and all of those underlying cultural realities where everyone is self directed, focused on the goals and willing to go with the whole approach will just fall into place... yeah, right!
In most cases, even when Agile is an active goal, what the customer wants tends to be what the team works on, methodology notwithstanding (in fact it's often not standing, it's set aside as often as its espoused). It takes a lot of behavior modification to make Agile work. Managers need to let go and stop micromanaging. Scrum Masters and PM's need to step back and realize that they guide and direct, they don't run everything. Most important, not everyone is on the same continuum. Development isn't in a vacuum, the rest of the company has to be on board with these changes as well.
A company's culture can be both wondrous and insidious. Regardless of where on the continuum you fall, it's important to realize that the culture is often deeply ingrained, and that culture can sabotage all of your efforts if you are not focusing on it. It's difficult enough to change one person's focus. Getting a full team or company to play along is a significant challenge. Coaching and mentoring is often needed to help foster this change.
Selena talks about an idea of "Living in Clover" and from that idea, she talks about "Clover Culture" which goes through 9 "C" concepts; Common values, Connection, Clarity, Creativity, Commitment, Collaboration, Cultivation, Competence and Communication.
- Common Values: Start with a common base, determine the teams values.
- Connection: Build connections to and relationships with people.
- Clarity: Seek first to understand.
- Creativity: Dare to look at other ways to do things.
- Commitment: Do what you said you would do, when you said you would do it, the way you said you would do it (i.e. the Larry Winget Golden Rule :) ).
- Collaboration: Work together... no seriously, work. Together!
- Cultivation: Succeed by giving your team members the chance to stretch and grow.
- Competence: once you've stretched and grown, harden that skill and keep upping your game.
- Communication: Once you have understood, seek to be understood.
Good suggestions and good ways to make it possible that we all have a better relationship with our team members and understand what we need to be doing to make our teams rock. They won't rock unless we make them rock, it's that simple!
Our third talk of the day is from Lanette Creamer and the topic is about "Avoiding Agile Perversion". Lanette has recently branched out and developed her own company, and these changes in her reality have helped to shape the way that she looks at things. When we "pervert" something, we are taking something that was defined one way and misapplying what we are supposed to do. What we are supposed to do is certainly subjective, and varies in different scenarios, but generally speaking, when the functionality of a process is called into question, that's a time to step back and reflect on what we are doing. This seems like a good example of when we see "small a" agile and "Capital A" Agile. We often think in terms of one or the other (I consider my team to be more of an agile team in that there are certainly areas that we don't to the letter follow every single element so that we could qualify for "Agile(tm)" designation, but we're pretty close in my mind.
There are lots of reasons why teams implement Agile transitions. They range in several ways from faster time to market, to better code development, to helping deploy continuously, to taking on features and testing simultaneously, to getting out of the death march mentality. These are all legitimate reasons, and they may all help encourage a transition to Agile. It's important to realize that we will have stumbles, we will have setbacks, and we may not get everything into play at the outset. That's not necessarily a bad thing. As long as we are striving to get to that place, we're probably on a good track.
Agile doesn't mean that all our problems will get fixed. It may help us identify them faster, but the fix may take much longer to implement after we have identified the issues. We often have a problem with admitting we may well be in the wrong, or need to make changes for ourselves for the other changes to be effective. Yet change we must if we are going to be effective. Clint Eastwood famously said "A Man's got to know his limitations" (note: that's all encompassing "man" in the generic sense). There is a level of exhaustion that we can't just overcome with more effort. Time and rest and recuperation are needed to get these things in place.
Many of the projects that failed that claimed to be Agile seemed to have a special kind of Agile system called "Don't Know". A lot of teams that claim to be agile really don't know what they are doing. Evaluating the transitions are often difficult, because we don't necessarily know when we are effective, or if we have to hybridize our systems while we put a more formal structure in place. Sometimes, we have to start in a place that's less than optimal, but start we must.
Lanette shared some various flavors of Agile Perversion:
Velociraptors: losing people, urgent fixes, no dates changed, heroics required. Survivors rare. To defend against Velociraptors, there needs to be a sacrificial victim, and each week, the person would change. A rather clever defense, I must say. The point is, there are always crises, we just need to ultimately manage and neuter the Velociraptors.
TallyMeasles: accounting and counting, it's all about the measurements, and what we do alone. It's all about the points. Politics are rampant, little is done for the needed areas, unless they help the point count. Whole Team is not in effect here. It should be and needs to be.
Fearcidity: Firings and layoffs happen frequently. People don't want to step out of their comfort zones, no one takes any risks, paranoia runs rampant, team members avoid each other unless absolutely necessary. Do not manage by fear, it's a lousy motivator.
Victimiosis: team members lose faith in the team, no hope for improvement, environment is toxic, unable to make improvements. Do your best to try to rid your team of this fear, give them ways to realize that they don't need to be afraid. Change the environment, run retrospectives and do what it takes to change the organization. Barring that, change your organization!
Agilepocalypse: This is the Agile at all cost crowd. "Too much Agile, not enough listening to the users". Very holier than thou approaches. Agile perfection isn't a destination, it's a process, and it's one that requires growth and continuous improvement. Agiler than thou is really not required, nor is it desired. Without good interactions with our customers, what we have is a pile of tools we're really good at using.
The point with these "perversions" is that they can be overcome. They might take time, they might take a lot of sweat and effort, but ultimately, to get beyond them, teams have to be committed to getting past the cultural baggage.
Tomorrow is the last day, and during the second hour is my turn! Hope to see you all there.
No comments:
Post a Comment