It’s OK – I do too.
I also enjoy reading a well-researched article in, say, the Harvard Business Review or the Wall Street Journal that validates what we do every day in the Lean-Agile community. It shows that they want what we got (and sometimes, vice versa).
But I recently happened across the April 2011 issue of Real Simple magazine, the riveting theme of which was “Spring Cleaning”. My curiosity as to how that subject could possibly warrant an entire issue led me to thumb through the pages until I came across an article entitled “This is Your Brain on Procrastination”, written by Amy Spencer.
The article presented the following list of things to do in order to get important things done around the house:
- Do the worst thing first (you won’t have the energy to do it later)
- Start your day over at 2:00 PM (assess and adjust regularly)
- Make the job smaller (and do it just “good enough”)
- Create an audience (make yourself accountable)
- Race the clock (see how working in short, timed bursts affects your productivity)
- Don’t interrupt yourself (or let anyone else do so)
- Plan an unprocrastination day (prioritize and then immediately DO)
Sound familiar? I thought so, too.
Yes, three years ago, guidance for which people still pay good money to be Agile-certified was published in an article on getting ahead on household To-Dos. That tells me that maybe Agile isn’t so special anymore.
I think that’s actually a good thing.
Why? Because I noticed a long time ago that most of us tend to use one system of thinking at home, and another when we’re at work. It’s almost as if we swap brains somewhere between the front door and the driveway.
For example, Home Brain says, “I have only so much money and so much time, so I’m going to have to accept the fact that I can’t have both a new refrigerator AND a new fence.”
Work Brain says, “Based on our best information, I know we can only really do the fridge. Tell you what: I’ll throw the fence in as a ‘stretch goal’.” (Home Brain’s too smart for that. He knows what stretch goals turn into.)
My efforts over the last several years, to a great extent, have been focused on simply getting people to take their Home Brains to work with them. The addition, now, of even informal Agile thinking to Home Brain’s innate clarity and common sense will make it that much more valuable at work.
So what if Agile’s mysteries are being divulged to the uninitiated as they stand in the supermarket checkout line? If value-oriented and throughput-focused thinking can permeate such mundane areas of our lives as decluttering a closet, then the the way we are trying to shape how we think at work will become more similar to how we think at home.
That should make bringing an Agile mindset into the workplace more natural. I’m OK with that, even if it means Agile loses some of its status in the process.
I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying
"Rachel mentioned about few questions that she uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team."
So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions.
Well just to be clear, I don’t follow an exact format or set list of questions -- I’ve been coaching for so long that questions seem to come burbling out of my mouth without much premeditation or forethought. Here's what I think I ask but this might actually differ a lot depending on the person or current issues.
Before we head off to our meeting, I check “Is now a good time for you?” and I’m fine to move to another time or skip the meeting. Coaching is always optional.
Once we sit down, I tend to start with open questions like:
- “How are you doing?”
- “Are things going well at the moment?”
- “Are there any issues you want to discuss?”
This tends to open out topic areas that we kick around -- discussing root causes , trying to see events from other perspectives and identifying possible courses of action.
I also look back in my notebook to see whether we talked about any specific issues at our last meeting:
- “Last time we discussed pair rotation in your team, is that working better now?” or
- “You facilitated a retrospective for the ABC team last week, how do you think that went?”
If they led a meeting, I ask if they’d like any feedback from me.
I might also mention current events such as team or process changes:
- "We have a new developer joining your team next week, have you thought about how she's going to get to know the system?"
- "We've changed the story time meeting format to run it with both teams together, how do you think that's working out?"
If the conversation dries up then we move onto specific areas such as personal development:
- “What research projects/Gold Cards have you been working on lately?”
- “Got any plans to give a lightning talk about that next week?”
- “You mentioned that you were planning to submit for XYZ conference, have you sketched out an abstract?”
I usually check at the end “Are there any other things you wanted to discuss?” and let them know that I’m around to discuss further any time.
There are no magic words or special incantations that I’m aware of. The main thing is to focus on what the other person has to say and try to listen carefully to what they’re experiencing and changes they wish for. I care about whether they’re happy at work and hope that talking will help them stop worrying about things that are holding them back and start acting on their concerns and ideas.
I’ve never been much of a blogger. The concept of short but frequent commentaries on subjects causes the perfectionist in me horror. I hate failing on a deep visceral level. Even my small failures tend to cause me distress for weeks or months after whatever the mistake was.
My personality tends to stop me from starting things that may fail, but others deal with failure in other ways. Some try to hide the failure, others deny that a failure is actually a failure and continue to go along without making any sort of correction.
In business today my personal preference for failure avoidance is typically not an option. If we don’t do anything we don’t make money and we are probably involved in defrauding investors somewhere along the line, so we will just brush that one aside for the moment. The other two are the ones that I would like to address, because these are what Agile and very specifically Scrum looks to help us overcome.
This difficulty often results in failure, as it should. Sadly the reaction to this failure is all too often; “We can’t do this” when it should be “How can we make this work”. The software industry has clearly demonstrated that Scrum is not only possible, but optimal. There is no business that Scrum could not be applied to successfully (should it be applied is another debate).
In truth, dealing with the problem of an organization trying to hide failure is a simple one, all you have to do is practice Scrum and everything will surface. Dealing with the denial of failure is a bit trickier.
In most software organizations we are conditioned to be horrified by failures because in a traditional waterfall structure they are catastrophically expensive. At best we have lost months of work, and at worst, years. Scrum allows us dramatically reduce the impact of these failures by taking them to a place where we have lost 2 weeks at most, or more typically a day or two. The trick is that even though these failures are not costly, our reaction to them is the same as if they had been. We don’t see them as the valuable knowledge growth they represent; we see them as the end of the world.
In any sort of bureaucracy the instinct to hide or deny is strong, but if we can bring people around to an understanding that failures are simply part of the normal course of business, to be learned from and used to drive adjustments, we can start to overcome the denial.
In the end it is all a culture shift. Adopting Agility in an organization requires self-reflection, asking ourselves why we react as we do to failures. Admitting that aspects of our business that we just assume to be “normal” are actually failures and should be addressed comes with this. It’s a frightening thing to put together a proper list of impediments to success, but a necessary one.
Scrum shows us what is wrong, but we still have to fix it. The final, and most important piece of this is understanding something that years of conditioning has destroyed in most organizations; Just because something is broken doesn’t mean we have to fix it today, or ever. Part of why we hide, avoid, and deny failure is because we think that as soon as we know about it we have to fix it. Not true, not even possible in most cases. We have years, decades even, of problems to resolve, it’s going to take a while, but if we don’t dredge them up, admit to having them, and work out a plan for fixing them, they never will be.
The post Grasping Agility: Agility, Personality and Failure appeared first on blogs.collab.net.
User stories also fall into the all too common trap of defining a solution instead of presenting problems to the team
- Elephant Carpaccio facilitation guide (or how to break user stories into thin slices) – by Henrik Kniberg http://t.co/y2wFuK7SpM
- User Stories & Back-End Systems | by Mike Cohn http://t.co/imWp91Irqm
- Small Stories Reduce Variability in Velocity, Improve Predictability – by LeadingAgile http://t.co/5njLoVDGdF
- ATDD in scaled agile environments | by Markus Gärtner http://t.co/lOpbK3YZpq
- How to Manage Large Agile Enterprise Programs with Features – by Leading Agile http://t.co/wqHYZN4b3V
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
Ah, tech writers. We do more than tell the user how something works -- we also explain the caveats and intricacies behind why a feature or enhancement functions the way it was designed. It’s a tech writer’s job to learn and communicate the value of any software we deliver to customers.
Since our Rally Help site contains over 1,000 pages of content, it’s imperative that we interface with other teams on a predictable cadence so we know what needs to be updated or refined. Our content also relies on the feedback we receive and our customers’ expectations that they have the online help they need at their fingertips.
Over the past year our User Learning team has worked hard to become a highly productive, relevant, and visible team that is responsive to customer needs and expectations. Here are a few examples of challenges we've met and solutions we’ve provided.Challenge: Our customers need more than written help
Solution: Give them what they need!
Our team creates written content, videos, and tutorials to cater to many different learning styles. Last year, we decided to create a new type of content: GIFs. GIFS are a dynamic way to show what it looks like to use a new enhancement or navigate to a specific place.
When you think about it, who has time to read through extensive documentation? Any time we can create a GIF that shows you how to do something in less than 10 seconds, we do it!
For example, here’s a GIF that shows you how to mark a card on a board as ready to pull or blocked:
Great end-user documentation is much more than mandatory written instructions. Breaking content into easily consumable bites and leveraging technology like GIFs and video is critical. Whenever our customers need to gain an understanding of new functionality, our team works to create easily consumable content.Challenge: Our team is the last to know about a new feature or enhancement
Solution: Collaborate early and often
When a feature or enhancement is released, the work of tech writers is often viewed as an afterthought. After planning, the product owner should be able to provide the tech writer with a timeline and enablement information for a new feature or enhancement.
So our team reaches out to product owners for details on business value, timeline for release, and user enablement on at least a weekly basis. We also get invaluable input from our user experience team, developers, and testers concerning issues that users may encounter with a new feature or enhancement.
We attend weekly feature status meetings and occasionally sit in on another team’s standup if a large feature is coming out soon and frequent changes might affect our documentation or videos. We also lead weekly meetings for other teams to learn about upcoming releases and review recently updated documentation.
This visibility with other teams has greatly increased our preparedness when documenting new features. Plus, we get the added bonus of seeing how the feature evolves week-by-week before it’s released to our customers.Challenge: Feedback is second-hand, and mostly internal
Solution: Give customers the opportunity to provide direct feedback
While our team has received great feedback about our Help site from people who work here at Rally, we realized we were missing something: direct feedback from our customers.
That’s why we implemented a feedback form on all pages of our Help site. We receive daily feedback and we read each and every message we receive. Yes, reading through all of these messages takes time, but it has opened our eyes to who is using our content and how they use it, as well as helped us identify gaps in our content.
This direct customer feedback has been critical to improving our content. Our users have contacted us about everything from broken links to clarification about the functionality of a burndown chart.
Over the past year, our team has learned how to engage both the internal and end-user consumers of our help content. Now, instead of being an afterthought, the content we create is an integral part of creating value for other Rally teams and our customers.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Over the last week I’ve quietly added a new product to the shop; free Agile Estimating cards as a downloadable pdf. The pdf contains my standard T-shirt sized estimating cards, and I’ve included a few other fun varieties including beer sizes and zombie weapon sizes.
I’ve also includes an introduction on Agile Estimating, and how to play estimating poker. You can pick up the free pdf’s here, and you can see a sample of the decks below:
If you’d like a more professional deck of T-shirt estimating cards, my original T-shirt estimating cards are still available. Printed on robust card stock, each deck has enough for a 9 person team so you’ll only need one deck per team.
The post Free Agile Estimating cards you can print (including T-shirts, beer sizes and martian weapon sizes) appeared first on Scrumology.
Andrea Chiou is a consultant in change management, team facilitation, agile and lean methods, and team and personal coaching. She blogs about her experiences at Adaptive Collaboration.
When we moved to Africa, and I was just going into 6th grade, I learned by observing that shooting off the tail of a gecko doesn’t do anything harmful to them. They do not bleed. They just grow the tail back. My brother used to do this with his little suction dart gun. There weren’t a whole lot of activities for young kids – we just used our imagination. I did try to stop him, but he was not stoppable. There were a few options: intervening when he was about to do it, finding the gun to hide it, or explaining to him that he just ‘shouldn’t’. I preferred the latter because it was easier for me to execute, but it was not effective.
Logic doesn’t usually work to get people to change their behavior. So, what works? What is the root cause for the resistance people have to logic. I’ve been exploring these types of things to figure out how I can be effective as a change agent.
One answer of several intriguing options is Clean Language - a very powerful coaching approach to help people discover new ways of thinking based on metaphors!
Humans frame all experiences uniquely as we experience the world differently in the metaphorical landscape. To make a change in your life, a Clean Language coach helps a person or group discover their own metaphorical landscape surrounding a goal, issue, problem or idea.
Clean Language is a process by which one explores an issue through ‘Clean Questions’. These questions guarantee to remove the possibility that opinions, judgements, expertise, suggestions, and other types of undue influence by the coach/helper/questioner enter into the picture.
Examples of Clean Questions (just a few) are listed here. X would be replaced by the exact noun or a phrase used by the person seeking help:
- And what kind of ‘X’ (is that X)
- And is there anything else about X?
- And that’s X like what?
- And what would you like to have happen?
- And what needs to happen for X?
Try this yourself. Catch yourself wanting to respond with your own opinions or stories to someone who has just said something interesting. Imagine that they have more to say. Then pick one of the first two questions using a phrase or noun of theirs and see what it feels like to let them continue by asking them of these questions. You will consciously be allowing your conversation partner to develop their thinking. Simple. And good! You will become a better listener too.
But a Clean Language facilitated session can be even more powerful. A Clean Language session involves ‘intense listening’ by the coach, and intense discovery by the person seeking Clean Language assistance. As a coach, not giving solutions is quite a mental challenge and takes practice.
I recently practiced a Clean Language session for the first time with someone who needed help. Aside from the beginning and the end of the session, I spoke only a handful of times to ask some Clean Questions, using a few words from the other person to guide them into further exploration. By the end, I was completely exhausted! But the fabulous reward was – my coachee said that she thought the session was so incredible because ‘all the ideas for her resolution came entirely from her and not from me’. ‘She would never have thought of them without the session.’
What a wonderful testimonial on the ‘regenerative’ power of using Clean Questions. Like the Gecko’s ability to grow back his tail, the capability to grow from expanding one’s metaphorical landscape is inherently human.
For those of you who are still curious, there are a few options. One is: buy Judy Rees’ book, ‘Clean Language, Revealing Metaphors and Opening Minds’. That is where I started my learning. Another option can be to learn about it through a new web site Judy has created called Learning Clean Language. This site has video tutorials of Judy introducing the concepts of Clean Language. She is developing this site in a very agile way, with periodic releases, and ample feedback mechanisms so that she can help you learn and you can give her feedback on the site. You do need to register and create an account, but otherwise it is free.
This post originally appeared on Andrea’s blog on 4/11/2012.
Most software development companies measure productivity of teams and individuals. Those measurements are then used to rate the individual or group performance. Numbers are so nice, cozy and familiar. They make things simpler; and if someone’s productivity can be objectively rated with numbers, lucky is this person and lucky are the managers of this person. This person is lucky because the clarity of numbers backs the clarity of expectations, and if someone knows that they may get a raise if they hit a certain number of whatever, that’s great. Managers are lucky because they are spared the need of figuring out how the heck to rate people, so they can be given or refused a raise, or a promotion, or a reward. However, in some cases mapping the actual value of an individual’s productivity and contribution to numbers might be challenging, if not at all unattainable.
Let’s look into the reasons why individual productivity is measured by counting things. This habit can be traced back to material production, or to any activity to product tangible things. If a farmer picks 100 vs. 50 cabbage heads per day, just an abstract example, this is surely good. One can not let a cabbage that is ready to be harvested sit for too long out in the field; it may fell prey to some pests, etc. With cabbages it surely makes sense to move fast, if we’re concerned with harvesting solely. By the same token, a baker who runs a bakery on a busy street is more productive if she bakes more croissants. The logic is flawless: more croissants, more customers served, more profit.
With this measurement model looking so clear and simple, it’s very tempting to copy-paste this practice of “more is better” to knowledge work. The non-material production. They used to measure productivity of developers by lines of source code produced per certain amount of time. I wonder if someone still uses this metric. One smart person has something to say about it.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Other equally poor attempts to measure productivity include: count of bugs discovered by a QA (what if this person tests the heck out of a feature, making sure it’s clean, and finds no bugs?); the count of words in a written piece, or the count of graphic icons designed per day. These are abstract examples, and, thank God, it looks like most of the software development companies moved away from those naive metrics. The less is more adage is grasped better now, when we seem to live in the age of super-abundance of everything (which doesn’t save us from the chronic shortage of value).
That’s the word. Value. How much shippable, valuable, finished work has this person done? Working many hours is far from being equal to super productivity and, after a certain point, indicates inefficiency. What I call “productive” is when one uses time in the office wisely, rather than works around the clock. Then, which contribution is this person making to the group? What does he or she do to improve the workflow, or to keep the integrity of the team? Naturally, being a group contributor means that this person is biting some bits off of their individual contribution. What if this person contributes at a larger scope, beyond their core skill? Then, how to factor in the subtracted individual performance when measuring productivity?
With these intricate nuances, I wonder if someone is ever able to quantify them and use it as a numerical measure of productivity. Surely, the kingdom of tests and grades has its doors always open, as it attends to the needs of busy managers looking for fast and clear ways to rate a person’s performance. But, as often is the case, the flip side of fast is slow. Individuals concerned with the team’s success are the keepers, and if a numerical grade fails to code the value of this person correctly, they might be demotivated. We all are human, and managers are human as well (in case someone ever doubted that). They want to rate the performance of teams and individuals faster, especially if a company is large. Better safe than sorry, stakeholders better make sure they can trust the scoring methods. Otherwise, it would make more sense to stick to the old-school ways: observe people, what they do, and see if this brings value to the company. We know that it sometimes takes years for judges to be ready with their rulings. It might take what appears to be an eternity for a snail to figure out what’s inside this bubble. A rainbow or gas stains? But the time spent on deciding is well worth it.
Image credits: Vyacheslav Mischenko
Over the last 20+ years, I’ve enjoyed more of my career as a Business Analyst than in any other role I’ve been able to play on a team. The control freak in me loves to practice my Project Management skills, the perfectionist in me always loved getting into Testing roles, the innovator in me loved trying my hand at Product Management. But the perfect balance, for me, is in playing the Business Analyst role.
As the consummate “contractor” for the first 20 years of my career, I was able to play the Business Analyst role in at least 10 different companies with 50 different ways of doing things. For the past 3 years as a consultant and trainer, it’s been my pleasure to work with another dozen or so clients with specific emphasis on Business Analysis skills. I want to share with you how Agile has changed the way I see this role and challenge you to try something new, if needed, to survive in an environment (and industry) undergoing drastic changes in expectations and practices wherever the word “Agile” is uttered.The Traditional Business Analyst
In the previous century, the typical cadence of a Business Analyst (at least from my vantage point) looked something like this:
- Spend a month or two with the Project Manager and Project Sponsor developing a charter and business case to present to the leadership team for approval and funding
- Spend a few months meeting with stakeholders from across the enterprise to define the Business Requirements of the project and to analyze the impacts that needed to be documented
- Once the 300-page Requirements Package was signed off by 23 people, consult to the design and architecture team as they developed the technical implementation and documented the details – inevitably revising 298 of the original 300 page Requirements Package multiple times and taking it back to 23 people for their review and sign-off
- When the epic novel of details was handed to developers, make sure that time was set aside from the new project that I was moved to in order to answer questions and continue revising the 300-page Requirements Package that I started writing 6 months ago
- As the behemoth of documentation and code was handed off to testers, make sure that I made myself scarce and referred to the 300-page Requirements Package I wrote a year ago as the “source of truth” for what needed to be tested
I’ve never been one to dwell on painful things for long, so this approach just didn’t sit well with how I view life and wrap my mind around how the world works. It’s too slow, drawn-out, full of surprises and rehashing of ideas and details that I would often like to forget. I wasn’t going to survive my career choice given how things were going.The Agile Business Analyst
When I found Agile, nearly 10 years ago now, that changed to some degree. Life moved at a more acceptable pace. The Agile Business Analyst cadence looked more akin to:
- Spend a day or two with the Product Manager to identify the Vision of an upcoming release or new product
- Spend a week or two defining the Epics and Features necessary to build the MVP necessary to meet the needs that the Product Manager envisioned
- Iterate around the most important and necessary Stories that were important to the release for a week or two with the Product Manager, various stakeholders and even customers to write User Stories in a simple format that were no more than 1-2 pages in length, and make sure that I fully understand the criteria by which the customer, Product Manager and users would be measuring successful implementation of a small, compact story
- Once I had the Acceptance Criteria well-formed and meaningful, work with the delivery team in Backlog Grooming sessions to make sure that the details were clear, understood, estimable, and informed what they needed to do to code and test the small packet of functionality
- During a Sprint in which a Story was being developed and tested, answering the day-to-day questions was much simpler and rarely required the revision of details, certainly not 298-pages of details
- On occasion, I would find that there are small gaps in understanding and the “shuttle diplomacy” of clarifying the details between the delivery team and Product Manager or customers would begin, but the process seemed to be faster and simpler than it ever was revising a 300-page Requirements Package
I wasn’t a fan of the “shuttle diplomacy” and frequent Story Review sessions, but I understood that this was a better way to get input from the delivery teams regularly but still “protect their time to code and test” to deliver requirements I had written for them in the previous weeks. Agile, and the use of Stories vs. 300-page Requirements Packages had made my life more bearable!The Aha Moment?
Then, something unexpected happened. I started working with clients in Story Workshops and changed the format that I’d been following. Instead of meeting independently with Product Managers, stakeholders and customers to define Stories, then meet with the delivery teams to refine the details, I started to bring some members of the delivery teams with me. In a room, I could have the Product Manager, 3-4 Stakeholders from various parts of the business, an Architect, a Tech Lead, and a QA Lead. Sometimes I’d even have my UX Designer there.
At first, this was unsettling. I was used to facilitating in a controlled environment with just a handful of people at a time and scribing the Story details as they were being discussed. In the first round of story discussions, I could project the Story and show the Product Manager and stakeholders what I was typing, have them validate and wordsmith/improve as we went. The follow-up with the delivery team was a similar approach – projecting what I had crafted and scribing additional details and documentation as we talked through it. But that was simply not going to work in this new venue – not with up to 10 people in a room; some of whom didn’t even speak the same language (“business” vs. “technical”) and all of whom had differing opinions on how far in the details the discussion should go. I thought I’d made a mistake in trying this out and was tempted to go back to shuttle diplomacy as my form of implementing progressive elaboration of requirements.
What would you do?
Lucky for me, I have a network of wise and experimental mentors who advised me not to give up. The benefit of having the people who need the work in the same room as the people who did the work (to write the software) was too valuable to give up on. They encouraged me to continue this approach and advised me to bring help. I’m a control freak, remember. And a perfectionist. So that wasn’t easy. But, I asked for help.
The post How Agile Helped Me Survive Being a Business Analyst appeared first on LeadingAgile.
Seit einiger Zeit bin ich nun auf einem Projekt, in dem die größte Herausforderung darin besteht, Hardware, Elektronik und Software derart zu synchronisieren, dass der gewählte agile Rahmen nicht zur Farce verkommt. Ein wichtiger Teil dieser Herausforderung ist es vor allem bei der Entwicklung von Hardwarekomponenten, nicht versehentlich doch in der Wasserfalle zu versinken: Wenn die Anforderung lautet: „Als Hans-Peter möchte ich die Höhe meines Schreibtischstuhls per iPhone-App steuern, um mir nicht ständig die Finger einzuklemmen“, ist die Verlockung groß, zu sagen: In Sprint 1 machen wir erstmal drei Konzepte für höhenverstellbare Schreibtischstühle, dann wählen wir im Review das Beste aus und fangen in Sprint 2 mit der Detailkonstruktion an. Im Anschluss können wir dann die notwendigen Teile bestellen und wenn der Einkäufer die Lieferanten ordentlich auf Spur gebracht hat, können wir die Teile sogar schon in Sprint 3 zusammenbauen. Am Ende des dritten Sprints wird dann gereviewt und es passiert – oh Wunder – in der Regel Folgendes: Entweder es gibt Verbesserungsvorschläge, die in Sprint 4 eingearbeitet werden können, oder man merkt, dass das Konzept zwar auf dem Papier super aussah, es allerdings jedwede Praxistauglichkeit vermissen lässt. Das bedeutet wiederum, dass man zu einem der anderen Konzepte umschwenken muss. Zu allem Überfluss schieben Elektroniker und Softwerker jetzt schon die Frustkugel, weil sie noch von überhaupt gar niemandem nach ihrer Meinung gefragt wurden. Das Ganze hat dann den agilen Charme eines Hochseedampfers beim Rückwärtseinparken.
Die Kunst besteht also darin, auch hier das Prinzip „fail early and often“ bewusst anzuwenden und vor allem davon auszugehen, dass ich als Product Owner ein Team von Experten mit der Entwicklung meines Produktes betraut habe. Die Wahrscheinlichkeit ist also gering, dass ich statt eines Schreibtischstuhls auf einmal einen Terassenklappstuhl in Toskana-Optik bekomme. Voraussetzung hierfür ist allerdings auch, dass ich meine Akzeptanzkriterien klar formuliert habe.
Ganz ohne Konzept geht es natürlich auch nicht. Ziel muss es aber sein, bereits mit einem Konzept lauffähig zu sein und schon im ersten Sprint Konzept, Konstruktion und Bestellung unterbringen zu können. So kann, die entsprechende Lieferzeit vorausgesetzt, bereits im nächsten Sprint zusammengebaut und begutachtet werden. Tritt hierbei Feedback zutage, kann dieses ohne weiteres in den kommenden Sprint eingebaut oder eben in das Backlog für spätere Sprints aufgenommen werden. Sollte sich herausstellen, dass sich die Ausarbeitung dieses Konzeptes als komplett nutzlos erweist, kann das Team nun, ohne Zeitverlust, ein neues Konzept erstellen, oder es greift – beispielsweise bei längeren Lieferzeiten – auf ein in der Zwischenzeit erarbeitetes Konzept zurück und der Zyklus wiederholt sich.
Und wo sind die Elektroniker und Softwareentwickler in der Zwischenzeit? Na immer mittendrin! Die unmittelbare Zusammenarbeit in der Konzeptions und Ausarbeitungsphase gibt den genauen Rahmen vor, innerhalb dessen diese Komponenten miteinander zu funktionieren haben. Der Schlüssel ist auch hier mal wieder „vertraue dem Prozess“. Wer sich früher davon verabschiedet, bereits im Vorfeld alle Eventualitäten einplanen zu wollen, kann auch früher damit beginnen, das ohnehin aufkommende Feedback zu integrieren.
- Sie können abschalten, wir haben die Vision
- Test Driven Development (TDD) und Scrum | Teil 1
- Warum überhaupt schätzen?
The Heartbleed Vulnerability (a.k.a. “The OpenSSL Bug”) exists in implementations of OpenSSL, which is used to provide SSL/TLS content encryption HTTPS (as well as some VPNs and other services). OpenSSL is widely used, with the vast majority of its use is in open source products like the Apache web server and nginx running on Linux or other *nix operating systems. Even some networking equipment uses implementations of OpenSSL. While not used or implemented on Windows servers or IIS natively, OpenSSL can still be present and installed on Windows servers if you install it directly or as part of another product (for example, by installing the Windows version of the Apache web server.)
So, how does this affect Axosoft and you, our customers? Given that Axosoft does not use OpenSSL for encryption in our web servers, application servers, software products, load balancers, or any other server or network infrastructure, the Heartbleed vulnerability does not impact Axosoft services or our customers. Axosoft uses Microsoft Windows servers and its IIS web server for our company websites (Axosoft.com, store.axosoft.com, etc.) as well as all of our web-based SaaS products. Microsoft does not use OpenSSL for SSL/TLS encryption functionality in IIS, but instead use their own Secure Channel (SChannel) implementation to provide encryption services and functionality, and this SChannel component is not vulnerable to the Heartbleed bug.
For anyone who needs or wants more information, here is a short post on one of Microsoft’s TechNet Blogs that doesn’t get too technical: http://blogs.technet.com/b/erezs_iis_blog/archive/2014/04/09/information-about-heartbleed-and-iis.aspx
For anyone who may want a deeper dive on the technical side, there is an excellent post by Troy Hunt describing a lot of the details on Heartbleed: http://www.troyhunt.com/2014/04/everything-you-need-to-know-about.html
If you would like to test a site to see if it is potentially vulnerable, here is a site that people can use to test websites and see if they are potentially affected by Heartbleed: http://filippo.io/Heartbleed/.
We recently conducted a webinar called Dev Ops in the Enterprise with Forrester Principal Analyst Kurt Bittner, Gene Kim, co-author of “The Phoenix Project and CollabNet’s own Laurence Sweeny.
The audience engagement was fantastic and we received many insightful questions from our listeners. Here are a few I hand-picked from the audience for Kurt Bittner around: The Agile Journey Begins – or Ends – Depending on your Culture.
Doug: What are some best practices in measuring/surveying the current culture?
Kurt: Agile practices require cross-functional teams. An organization that has very strong role silos and strong role sub-cultures will struggle with Agile.
Agile works best with flat organizations with a servant-leader management culture. Organizations with a strongly hierarchical, top-down culture will also struggle with Agile.
Agile also works best when there is transparency and cooperation between the business and the application delivery organization. Organizations with an adversarial or contractual relationship between business and IT will struggle with agile. Contractual relationships are characterized by the need for contracts and signoffs to record commitments, especially where those contracts are used to transfer risk or to establish an audit trail for denial of responsibility.
Agile requires a learning culture, one able to learn from missteps or mistakes. A culture of blame that punishes failure and largely deals with it by searching for the responsible party and then punishing them will create a culture of fear that is extremely risk averse and unwilling to do anything with an uncertain outcome. Since most outcomes are uncertain these organizations get very little done beyond the status quo.
Doug: How does one obtain the proper buy-in on necessary changes?
Kurt: There must be a recognition at the top of the organization that the traditional approach is not working, and an imperative need to change. Leadership must create an environment in which innovation and learning are valued and rewarded. The focus must shift from protecting and rewarding the status quo to seeking out opportunities to improve, and rewarding results. The organization must be willing to break down existing silos and to dismantle the siloed fiefdoms that often permeate traditional organizations.
In addition, obstacles must be removed from Agile teams. Operations should be streamlined so that appropriate development and test environments are available whenever they are needed. Teams need appropriate tools right from the start as well – IDEs, SCM, continuous integration, and test automation. They need to be able to develop and test from the first day.
There is also a natural shift in focus from projects, temporary entities that have a defined start and end, to products that are funded and staffed as long-term initiatives. This also means that resources tend to be dedicated and not shared between initiatives.
Finally, the business needs to be fully engaged. They need to stop thinking of their involvement in developing applications as a part-time side project but a full-time commitment. The initiative needs to be important enough to the business for them to fully commit to being involved.
Doug: What are some lessons learned from implementing changes?
Kurt: Having environments available early in the project is really important. Standardizing environment configurations and being able to provision them on demand (sometimes called infrastructure as code) is very important for having those environments available quickly and eliminating hard to diagnose defects that emerge from mismatches in configurations between dev, test and prod (the classic “it works fine on my machine” bugs). Continuous integration is also a key enabler. Reducing batch size and branch duration is also key.
Engaging with the business is key; they need to be active participants, not engaged at “arms length” as they have been in the past. In some organizations the relationship between business and IT is so bad that this is going to be a challenge. The only real answer to this is evidence of improved delivery.
Lots of organizations fall into the “training trap”. They announce that “agile is the way” with great fanfare and even, in some cases, beautiful posters and “Agile newsletters”. They then send everyone to a training class, perhaps one resulting in becoming a certified Scrum master. They track how many people have taken the training and passed the test, and that’s about it. Training can establish a baseline understanding but it doesn’t usually achieve anything. People have to learn by doing. They have to be allowed to try and fail and learn. They need to be shown new ways of working by people who have already been through it.
Governance models reinforce behavior. If you measure projects using a schedule-driven set of milestones, the project will revert to a waterfall approach. You have to measure progress in terms of business value delivered in order to change behavior.
Architecture matters. If the application is a traditional legacy system “mud ball of code”, with tight coupling and poor modularity, it will be very hard to deliver in small increments. Not impossible, but very hard. Agile works better with mobile and cloud applications because the architectures of those applications tend to be loosely coupled. Loose coupling allows different parts of the application to change independently, allowing for faster delivery.
Doug: How does one get past the mentality of “There isn’t time to change how we do things, since we are already behind and the customers want us to move forward”?
Kurt: The Japanese poet Ryokan said “If you want to find meaning, stop chasing so many things.” The first thing you need to do is to reduce WIP. Most of that WIP is probably waste right now anyway. If you reduce the batch size, limiting the amount you are doing in parallel, you can then focus on trying to improve. The reduction in waste caused by too much WIP will give you the time and resources you need to get better. The challenge is recognizing, and getting the business to recognize, that a lot of what you are doing now is just waste. As once manager with whom I used to work wisely said, sometimes you need to go slow (at first) to go faster.
What type of Agile culture does your organization have?
Follow me on Twitter @dribback, @collabnet
The post The Agile Journey Begins – or Ends – Depending on your Culture appeared first on blogs.collab.net.
What an extraordinary conversation I had recently on Twitter. It started with Neil Killick’s statement that we should not consider our stories truly done until validated by actual use. This is a lovely thing, if we can manage it. While I’ve not set such a bold declaration of “done,” I’ve certainly advocated for testing the benefit of what we build in actual use. Deriving user stories from hypothesis of what the users will do, and then measuring actual use against that hypothesis is a very powerful means of producing the right thing—more powerful than any Product Owner or Marketing Manager could otherwise dream up.
While I often recommend such an approach as part of “Lean Startup in the Enterprise,” when I hear someone else say it, it’s easier to think of potential problems. Paul Boos says it’s “balanced insight.” I fear it’s me being contrary, but I do like to examine multiple sides of a question when I can. In any event, such conversations help me to think deeper about an issue.
The first situation I considered was the solar calibrator for Landsat VII. When you only get one launch date, it’s a bit hard to work incrementally, validating the value with each increment. Instead, we must validate as best we can prior to our single irrevocable commitment. This involves quite a bit of inference from previous satellites, and from phenomena we can measure on earth. We must also predict future conditions as best we can, so that we can plan for both expected conditions and anomalies that we can envision. This is an extreme situation, and it’s quite possible we’ll utterly fail.
So, the conversation turned to ecommerce systems. Surely we can measure user behavior and know what effect a change makes. We can measure the behavior, all right, but even without making any change, we may notice a lot of variance in that behavior. If a variance of 5% to 10% can be expected week-over-week in some measured behavior, then a change that might produce a 1% to 2% change is very hard to detect.
The obvious answer is to maintain a control group. If we present some users with an unchanged system and others with the change, then we can measure the normal variation in the control group and the normal variation plus the variation specific to the change in the experimental group. Given a sufficient number of users, the normal variation should be equal between the two groups.
Is, however, the specific variation a lasting phenomena in response to the essence of the change, or is it transient behavior triggered by the fact that there was a change? In spite of the Hawthorne Effect being a legend based on poor experimental design, novelty does attract interest.
When we gain in one respect, we lose in another. With either of these methods, there may be errors in what we think we know about them. And any time we segment, we’re reducing the quantity in a study group, increasing the chance that our measurements may be due to random chance rather than the change we are studying.
The use of statistics can help us estimate whether or not a variation is specific or random. It can tell us whether the change is statistically significant, and what is our confidence level that it’s not random. It cannot, however, assure us of our conclusions.
Statistics also can only alert us to correlation, not to causation. The behavior change we notice may be due to an overlooked difference that accompanies the difference we’re attempting to measure. If we’re not very careful, then there may be systemic bias that we don’t notice, and we make the wrong presumption from the evidence.
In the world of commerce, we rarely have the opportunity to repeat our experiments to see if they’re repeatable. We want to keep progressing, and so we lose the baseline conditions that would allow us to repeat. Also, our system is just a small part of the daily life of a potential customer. It’s just a small part of the larger system made up of all the other small systems they use. Those other systems also have the capability to change the user’s behavior with our system. Perhaps they change how the user perceives our system can be operated, or sets a different standard for what is considered acceptable.
The world is a bit unpredictable. In the end, we seem to be measuring what happened against what we estimate would have happened, otherwise. Sometimes it may seem very clear to us; sometimes murky. Always we have the possibility of fooling ourselves.
Der Ausgangspunkt dieses Beitrags war eine Diskussion zum Thema Testautomatisierung und die Frage, wie deren Vorteile und Nutzen einfach kommuniziert werden können. Mit welchem Beispiel aus der alltäglichen Praxis lässt sich die Testautomatisierung für Software am besten vergleichen? Mir fiel folgender Vergleich ein: Ist denn die Testautomatisierung nicht eigentlich eine Versicherung für die entwickelte Software?
Aber der Reihe nach. Per Definition sind Versicherungen dazu da, ein mögliches Risiko für einen Schadenseintritt abzusichern . Da Software heute in vielen Unternehmen essentiell für deren Wertschöpfungsprozesse ist oder sogar die Wertschöpfung darstellt, ist deren Berücksichtigung für das Risikomanagement des Unternehmens nicht nur sinnvoll, sondern notwendig. Im Rahmen des Risikomanagements müssen mögliche Schadensfälle definiert und bezüglich ihrer Eintrittswahrscheinlichkeit und -schwere klassifiziert und priorisiert werden.
Stellt euch vor, dass das betrachtete Unternehmen 50% seines Umsatzes mit Hilfe eines Online-Shops erwirtschaftet und in diesem wegen eines Softwarefehlers mehrere Stunden keine Bestellungen getätigt werden können. Im realen Leben ein Worst-Case-Szenario, das immer wieder auch renommierte Shop-Betreiber trifft.
In der Lehre des Risikomanagements gibt es verschiedene Varianten, mit einem Risiko umzugehen. Das Risiko kann in Kauf genommen, minimiert, an Dritte übertragen oder gar vermieden werden. 
Viele Firmen entscheiden sich bei Software unbewusst für die erste Variante, da sie diese Schadensfälle gar nicht berücksichtigt, geschweige denn berechnet haben. Erst wenn der Schaden eintritt, wird sich ein Unternehmen seines ausgesetzten Risikos bewusst. Dabei wäre es doch so einfach, das Risiko mit Hilfe einer Versicherung auf ein akzeptables Maß zu minimieren. Diese Versicherung ist die Testautomatisierung. Mit Hilfe unzähliger automatisierter Tests werden regelmäßig alle wichtigen Funktionalitäten der Software auf ihre Funktionstüchtigkeit getestet. Diese Tests liefern somit regelmäßig Feedback über das aktuelle Risiko, das von der Software ausgeht. Mit Hilfe von Statistiken und Auswertungen können diese Daten dann in eine unternehmensweite Risikoüberwachung integriert werden.
Testautomatisierung sichert so nicht nur nachhaltig die Qualität und Wartbarkeit der Software, sondern verschafft auch ein Gefühl der Sicherheit, die eigene Software „im Griff“ zu haben. So let us start coding test driven!
 Wiktionary: http://de.wiktionary.org/wiki/Versicherung
 Ahrendts, F.; Martin, A.: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung. Berlin: Springer Verlag, 2008.
- Test Driven Development (TDD) und Scrum | Teil 1
- Der ScrumMaster ist eine Versicherung (Mike Beedle)
- Prioritäten | Product Owners Tools
Today, we are announcing a number of very exciting changes to Axosoft and OnTime, so lets get right into them:
- NEW V14.1 released – Tons of new features. Check out our “What’s New” page here.
- Axosoft and OnTime branding changes – We are dropping the “OnTime” name from our hosted product, but keeping it for our installed customers. Read more below.
- New pricing for Axosoft Scrum, Bug Tracker and Premium Support – Lots of exciting changes to pricing that you can read about below.
Since Axosoft was founded in 2002, customers often referred to the OnTime product line as “Axosoft.” Axosoft has become synonymous with providing best-of-breed Scrum, Bug Tracking, HelpDesk and Wiki tools for software developers, so when we separated the Axosoft OnTime product onto its own domain two years ago, OnTimeNow.com, the change didn’t make sense to a lot of our customers. Quite frankly we were slow to realize this ourselves. Two years later, we’ve come to the same conclusion: The “OnTime” portion of the product name is largely unnecessary, especially in the new cloud-centric world.
Now, rather than “Axosoft OnTime Scrum” or “Axosoft OnTime Bug Tracker”, the new names of our products are just “Axosoft Scrum” and “Axosoft Bug Tracker.” The entire set of products is just the Axosoft Product Suite.
This name change makes it easier to just say “we use Axosoft” when you refer to our dev tools. As a result of dropping the OnTime name, it also made sense to bring everything back under the Axosoft.com domain. So while your instance of Axosoft Hosted products will continue to work under [AccountName].OnTimeNow.com, they will also work under [AccountName].Axosoft.com. The Axosoft.com version is preferred as we expect to phase out the old name at some point in the future.Keeping the OnTime Name for Installed Customers
For our installed customers, we’ve decided to keep the OnTime name. This makes it easier to find your downloads, manage the OnTime Services on your servers, and any other dependencies you have built in your installed system that depends on the OnTime naming convention.New Pricing Changes
Lets start with a quick price matrix of the products that are affected by the pricing changes:
Of course, the most exciting pricing announcement is that we are making the Axosoft Bug Tracker just $1 per year (or free with any other product) for teams of any size. This is an unprecedented move by any developer tools vendor. Never before has a full-featured bug tracking product been made available as a hosted solution to software development teams for practically free. This is big. Imagine every software development team around the world having access to a high quality, feature-rich product for tracking their bugs and working together as a team. We fully expect that Axosoft Bug Tracker will become the de facto standard bug tracker for dev teams worldwide.So why are we doing this?
The why is easy. We love software and we want software developers to be able to create even better software. Tracking bugs is a fundamental requirement to creating great software products.
You might be asking yourself, “what’s the catch?” or “how can you afford to do this?” The answer to that is scale. We now have over 10,000 paying customers for our highly popular Axosoft Scrum software (as well as Axosoft HelpDesk and Wiki). This is a great way for us to give back to the community. Plus, something tells us that giving more development teams exposure to the Axosoft Product Suite through Axosoft’s near-free Bug Tracker will probably make our products even more popular than they already are. So while we do expect to benefit from the $1 Axosoft Bug Tracker, there truly is no catch for the customer. Buying Axosoft Bug Tracker for just $1 per year doesn’t put you on the hook for anything more!What’s the deal with the $1? Why not free?
There are two reasons for this: 1) We don’t want to get a zillion junk accounts that will never be used. A little skin in the game, even when it’s just $1, goes a long way to ensure only interested parties apply. 2) Collecting even a nominal fee of $1 gives us the opportunity to support new software startups with a new $10,000 grant program. We love software companies and this grant program gives us an opportunity to support new software startups with both money and mentorship that they badly need to build new products.Wait, I’m paying $7/user for Scrum or Bug Tracker, is my price going to change?
No. If you have Axosoft Scrum at $7 per user, even though we are raising the price to $10 per user, your price will remain the same $7 per user that you have been paying. Also, if you only have Axosoft Bug Tracker and were paying $7 per user for it, we kept your price the same, but added Axosoft Scrum at the same rate because the $1 bug tracker no longer has burndown charts and other features that are specific to Scrum. By adding Axosoft Scrum and keeping your price the same as before, we make sure you don’t lose any features and your price is unaffected.Can I change my configuration to downgrade to just the Bug Tracker for $1/year?
Yes, absolutely. Any existing customer can modify their account through the Tools Menu -> Account Administration.
The real lessons in software development come from production. The more frequently you can deploy – more feedback you can generate
- Software Design 21st Century by Martin Fowler http://t.co/6Fb3hQMV6X
- Programming Laws and Reality: Do We Know What We Think We Know? | Dr Dobb’s http://t.co/iUy3k9mxFj
- Rob Myers experiences with TDD – An open letter to the Editor in Chief of Dr. Dobb’s http://t.co/61zJtpx5xg
- Workflows of Refactoring – slide deck by Martin Fowler http://t.co/j3MyjFcsbp
- Rocket Powered: A Ranty and Dogmatic Troll Masquerading as Coding Guidelines http://t.co/pUSUvcE3Zq
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.