Skip to content

Feed aggregator

Error Monitoring Application Bugsnag Releases Assembla Integration

Assembla Blog - 6 hours 22 min ago

Bugsnag is a web and mobile error monitoring application that detects and diagnose crashes within your applications. They recently informed us about their new Assembla integration that can create Assembla tickets for detected errors allowing your team to quickly start squashing these errors via Assembla tickets.

To set up this integration, you will first need to have a Bugsnag project up and running. To try Bugsnag out, you can sign up here. From your Bugsnag project, visit the Settings > Notifications section to enable the Assembla integration. Once enabled, you will land on the integration configuration page that look like this:

bugsnag assembla integration

  • Determine when an Assembla ticket should be created: when the first exception of a new type (error) occurs, when a previously resolved error re-occurs, and/or when you manually click on “Create Issue” on an error within Bugsnag.

  • Space URL: Such as

  • Your API Key and API Secret: This can be created in your Assembla profile sidebar menu, or by following this link.

  • Tags (optional): This provides a default tag for all Assembla tickets created from Bugsnag such as “Bugsnag Error.” I personally love this part of the integration because with tag filters, you can easily see all errors that are being worked on and where they stand. To learn more about Assembla’s tag feature, check out our release announcement.

To learn more about other companies that have integrated with Assembla or to submit an integration for review, check out

Categories: Companies

Improved File Search: What You Need to Know

Assembla Blog - Thu, 04/17/2014 - 16:11

With the recent file search improvements, it is now easier to find the files you are looking for when you need them. With every file upload, we now index all the following elements: file name, tags, mime-type (media type), and author.

  • File Name: We now apply a word delimiter filter that splits words into subwords based on intra-word delimiters such as case transitions ("PowerShot" → "Power", "Shot"), letter to number transitions ("SD500" → "SD", "500"), and characters ("Wi-Fi" → "Wi", "Fi").
  • Tags: If you add the optional tags to a file, you can easily include a tag in the search parameters to locate the file.
  • Mime Type (Media Type): When a file is uploaded, it will be indexed with a media type such as hello.png will include “image/png” so it can be found with a search for “hello” or “image” or “png” or any combination like “hello image.” Almost all files have a mime type such as word, excel, zip, pdf, etc., and we now index them so you can locate your files easier.
  • Author: The author field consists of the user’s first name and last name as displayed in their profile as well as username. Usernames are also use the same word delimiter to split usernames into subwords. So if John Smith with username JohnRocks uploads a file, you can search for that file with “john” or “smith” or “johnrocks” or even just “rocks.”

Most importantly, the default logical search operation has changed to search for words using AND instead of OR when using a combination of words. For example, when you search “john image” it will return back anything that is an image AND that was uploaded by John.

We hope these improvements make file searching more efficient. If you have any other suggested improvements, please let us know on our feedback site.

Check out some other Assembla tips and tricks!

Categories: Companies

What’s So Special About Agile?

The Agile Management Blog - VersionOne - Thu, 04/17/2014 - 15:19

SpecialButtonAdmit it.  You enjoy telling people that you’re an Agile “practitioner”, “coach”, or “evangelist”.

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.

Categories: Companies

No Magic Words

Agile Coaching - Rachel Davies - Thu, 04/17/2014 - 11:45
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.
Categories: Blogs

Targetprocess Version 3 Launched

Scrum Expert - Thu, 04/17/2014 - 11:00
Targetprocess announced the availability of Targetprocess 3, which now includes more ways to visualize project data, track work across multiple teams and align business initiatives with development. This latest release reinforces Targetprocess’ dedication to offering a project management solution that improves visualization and flexibility, ultimately allowing organizations to make smarter, more efficient decisions. As today’s businesses continue to evolve, the tools that cater to them must do so as well. Targetprocess was created with the goal of bringing visibility into management and this concept has catapulted them as one of the ...
Categories: Communities

Grasping Agility: Agility, Personality and Failure

Danube - Thu, 04/17/2014 - 00:50

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.

 Agility, Personality and Failure

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

Categories: Companies

Five links on Agile requirements

User stories also fall into the all too common trap of defining a solution instead of presenting problems to the team






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: Please follow @agilequote for more quotes.

Categories: Blogs

How To Thrive As an Agile Tech Writer

Rally Agile Blog - Wed, 04/16/2014 - 13:00

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:

blockreadyreason (1).gif

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.

Erika Edwards
Categories: Companies

Understanding the Pull of SAFe™

NetObjectives - Wed, 04/16/2014 - 03:23
Plans are worthless, but planning is everything. Dwight D. Eisenhower One of the more misunderstood aspects of SAFe is it's Potentially Shippable Increment (PSI)/release planning event.  To me, this is one fo the most innovative aspects of SAFe.  Some misunderstand it and consider it to be a big batch up-front planning mechanism and then infer that the implementation of the plan is also based on...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Free Agile Estimating cards you can print (including T-shirts, beer sizes and martian weapon sizes) - Kane Mar - Tue, 04/15/2014 - 22:01

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:

Free Agile Estimating Cards

Free Agile Estimating Cards

Free Agile Estimating Cards

Free Agile Estimating Cards

And, the original T-Shirt size cards are still available.

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.

Categories: Blogs

The Story of Clean Language and the Gecko

Coaching Agile Teams by Lyssa Adkins - Tue, 04/15/2014 - 20:25

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.

Categories: Blogs

Measuring Productivity In Software Development Teams

TargetProcess - Edge of Chaos Blog - Tue, 04/15/2014 - 17:45

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.

the snail and the bubble

Image credits: Vyacheslav Mischenko

Related articles:

Why Fast Is Slow

How Communication Factors In To Production

When Intensity Pays Off

Categories: Companies

How Agile Helped Me Survive Being a Business Analyst

Leading Agile - Tue, 04/15/2014 - 15:16

Business Analyst

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.

webinar ad

The post How Agile Helped Me Survive Being a Business Analyst appeared first on LeadingAgile.

Categories: Blogs

Wer hat Angst vorm ersten Wurf?

Scrum 4 You - Tue, 04/15/2014 - 07:39

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.

Related posts:

  1. Sie können abschalten, wir haben die Vision
  2. Test Driven Development (TDD) und Scrum | Teil 1
  3. Warum überhaupt schätzen?

Categories: Blogs

You’re safe! Why the Heartbleed Bug Doesn’t Affect Axosoft

About SCRUM - Hamid Shojaee Axosoft - Tue, 04/15/2014 - 03:02


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 (,, 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:

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:

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:

Categories: Companies

The Agile Journey Begins – or Ends – Depending on your Culture

Danube - Mon, 04/14/2014 - 23:56

 After the Webinar – More Insights from the DevOps Experts, part 1Ask the Expert icon1 300x71 The Agile Journey Begins – or Ends – Depending on your Culture

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

Categories: Companies

Agile Webinar on Vimeo

This is the link to the video of the Webinar “Agile is the future” I held in March for PMI Rome.  
Categories: Blogs

Feature Board and Cards

Scrum Expert - Mon, 04/14/2014 - 20:46
Most of the Scrum teams use a task board to visualize their activity and progress with task cards. In these two blog posts, Keith Clinton, the author of Agile Game Development with Scrum, discusses the concept of feature boards and feature cards. Task cards contain information about individual tasks that will be needed to complete a set of features. Keith Clinton says that the problem of task boards is the lack of visibility of cross-discipline dependencies. In a feature board, cards move around the board depending on the work that is ...
Categories: Communities

Validation and Uncertainty

George Dinwiddie’s blog - Mon, 04/14/2014 - 16:54

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.

Another difficulty is that the people whose behavior we are measuring are individuals, and vary considerably from one another. When we measure in aggregate, we are averaging across those individuals, and smoothing the rough bumps off of our data. Unfortunately, much of the data is in those rough bumps. What motivates one person to purchase our product may drive another one off. Can’t we segregate our customers into different segments so that we can at least average over smaller, more-targeted groups? If we’re measuring behavior of customers who are logged into our site and whose background and behavioral history we know, then we certainly can. If they are anonymous users, then no, we can’t. Not unless we can spy on them by tracking them around the web through widespread cookies, surreptitious javascript, or other means.

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.

Categories: Blogs

Testautomatisierung – die Versicherung für Ihre Software!

Scrum 4 You - Mon, 04/14/2014 - 07:25

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 [1]. 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. [2]

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!

[1]  Wiktionary:
[2]  Ahrendts, F.; Martin, A.: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung. Berlin: Springer Verlag, 2008.

Related posts:

  1. Test Driven Development (TDD) und Scrum | Teil 1
  2. Der ScrumMaster ist eine Versicherung (Mike Beedle)
  3. Prioritäten | Product Owners Tools

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.