Troy Web Consulting uses Assembla Portfolio to answer questions like:

• What projects, sprints, milestone and tasks the team is working on?
• What are the highest-priority tasks across all of our projects?
• Who is overloaded? Where are resources needed?
• When will key developers be available for a new task?
• Has the client seen the system changes and what are their comments?
• Where is the needed documentation for the client, and what are the procedures for accessing their network, server and codebase?

A few years ago most of Troy Web Consulting’s business was from 10 government agencies near its home base of Albany, NY, including the New York State Office of Cyber Security and the New York State Office of Alcohol and Substance Abuse. When many agencies faced budget cuts, the company succeeded in diversifying its customer base to include a large number of private sector firms.

Today it works with 30-35 customers each year, which is good for business but also creates serious management challenges.

Manage resources across projects

A big win for Troy Web is the power of Assembla Portfolio to help them manage resources across projects. By answering the questions listed above, they improve efficiency, lower costs, and deliver work on time for their customers.

Troy Web used Assembla Workspaces for a long time, but found that upgrading to Portfolio gave them much more visibiltiy and control of multiple projects and developers who share time across projects.

Everything in one place to “hit the ground running”

With all those projects, Troy Web needs to be able to start up new projects quickly and maintain as much consistency as possible between projects. It does this by making an Assembla workspace into a template and copying that template for each new space. The template includes a consistent set of tools and features. It also includes a Wiki with documents like project checklists and key information such as access instructions for servers and other key resources. Developers like that they can find everything they need in one place so they can “hit the ground running” on new projects. New team members can also come on board faster.

Subversion and Git

Troy Web runs most of its projects on the Subversion repository, but also an increasing number on Git. A few projects use both; for example, for one iPhone mobile application they keep code for backend services in Subversion and executables for the UI in Git. Assembla allows them to use both repositories with exactly the same tool set, and with full ticket system integration. They believe this will become even more important in the future as more organizations transition from Subversion to Git.

Tying in Customers

Troy Web has also had success letting customers submit requests and comments in the form of support tickets though the use of the Support tool. The customers are happy that they can provide input easily, and the developers can respond more quickly to customer requests.

Great Support

According to Anthony DeBonis, Director of Application Development at Troy Web Consulting: “We really like Assembla. The service and support have been great. We have introduced it to many of our customers, and they also have been enthusiastic. We are very happy to recommend Assembla Portfolio to anyone who needs to manage multiple development teams and projects.”

                                                                                            By Dominica DeGrandis A collection of incredibly impressive thinkers and leaders from around the world has converged in Boston for the Lean Software & Systems Conference. This issue covers some of the many takeaways …. News Sunday’s Lean Camp (facilitated by Jim Benson) provided some amazing eye openers.  First, an opportunity to study two large Kanban implementations and discuss why one saw viral spread and the other didn’t.  Next, we played Russell Healy’s new Kanban system design game for Operations teams. Lastly, Jason Yip facilitated a well attended session on learning.  Takeaway - put yourself in uncomfortable settings to learn - else you risk falling back into your comfort zone. Day 1 The opening keynote with Steven Spear focused on achieving greatness through learning.  Spear suggests, “Find out what’s wrong with what you are doing and go tell a friend.”  An appealing storyteller, he demonstrates the need for senior leaders to demonstrate their need for more knowledge to motivate people to learn. David Joyce kicked off the Kanban track Monday morning with a talk on moving beyond the traditional PMO to 21st century portfolio management.  Takeaway – Include a “Study” column at the beginning of the board. Lightening and Ignite talks enlightened us all quickly!  Simon Marcus, @lycaonmarcus voiced his concern on the current trend of management bashing.  Between @stevenspear’s keynote and Simon’s lightening talk, my interpretation is the following if then statement:       if management is asking why       and not dictating       then don’t bash Videos from talks will be available through lssc.  In the meantime, slides from some talks have been posted on slideshare Day 2 Troy Magennis incited discussions on how teams can work with upper management to get reliable estimates using the monte carlo simulation.  Takeaway – The average is the worst value to use. Mary Poppendieck’s talk on continuous feedback included an engaging and interactive discussion followed on set-based decision making versus Multiple Viable Product and a/b experiments. Takeaway – These are not mutually exclusive, we just know when to do one or the other. Day 3 Don Reinertsen rocked the main stage with his talk on decentralizing control. Taking examples from the US military and the forest fire service, there are too many takeaways to list, but here are my top three: The important communication is lateral, and not from the top. You have a duty to disagree if you believe otherwise. If you think you can eliminate uncertainty, you’re delusional. Events Lean Software Systems Conference – Boston, May 13-18, 2012 (#lssc12) http://lssc12.leanssc.org/ Agile France – Paris, May 24-25 (#AgileFrance) http://conf.agile-france.org/ SFAgile – San Francisco, June 4-6, 2012 http://sfagilecon.org/ Resources Lean Kanban University (LKU) http://www.leankanbanuniversity.com/ Kanbanops http://tech.groups.yahoo.com/group/kanbanops/ Kanbandev http://finance.groups.yahoo.com/group/kanbandev/ Limited WIP Society http://www.limitedwipsociety.org/ #mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; } /* Add your own MailChimp form style overrides in your site stylesheet or in this style block.   We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */ Subscribe to Weekly Kanban Roundup Please contact dominica@djaa.com with questions.  

Asked on the Agile-Testing mailing list:

Lesson 136: Testability is often a better investment than automation.

(I’m quoting “Lessons Learned in Software Testing” by Kaner/Bach/Pettichord)

If anyone has practical examples of improving testability, I’d be very interested to understand, and grateful.

I first encountered the issues of testability when working with integrated circuit design in the 1980s. The same issues apply to software systems.

1.  You want to be able to easily put the system into a known state. It’s best if you can get to the state you want for your test without going through a number of interactions or other states on the way.
2.  You want to be able to drive internal nodes of the system so that you can test parts in isolation. It’s much harder to test everything through the GUI, public API, IC pins, or whatever is the normal interface.
3.  You want to be able to sense internal nodes of the system so that you can test parts in isolation. Like being able to drive internal nodes, this reduces the combinatorial complexity.
4.  The special access you add for testability does add some complexity, can provide new failure modes, and might leave some paths untested. Be aware of this and consider what these issues are for your system.

Your work gets a bit easier if you consider this as part of building the system, rather than just as part of testing it. If you build your tests first, the tests will specify the state and access you need for testability. Running these tests while the system is built will result in testability appearing almost magically. Because of that, I’d say that testability trumps automation only when you’re already late in starting.

This article discusses the the role of the Product Owner in moving a backlog item to done. It explores how to achieve the productivity benefits of an up-front enabling specification, given the reality that Scrum is an empirical framework in which emergent understanding of the story under development is inherent. “Done” is not some arbitrary state of a backlog item. When an item is done, users can take advantage of the new functionality and give meaningful user feedback. The article lists some common issues with software delivery: annoying user interface, busy ...

It’s almost a cliche in the consulting field that all problems are people problems… sometimes though, I don’t think we really appreciate the depth of truth in that statement. Improving the systems in which we work, introducing some new processes, or bringing in a new approach or methodology or tool requires people to change what they are doing today and requires them to do something different tomorrow.

Change is hard… change is scary… change isn’t safe.

I’m guessing that most of us have read Kotter’s work on leading change… and while I do believe that managing change… or even leading change… is an essential part of bringing new ways of working into any organization… it feels to me that there is something deeper, more personal around change than putting gloves on a table, or posters up around an office.  Resistance to change often runs deep for reasons that are not immediately obvious.

Let me tell you a little story about my wife and I growing up… while we both grew up in stable two-parent homes… our early childhood experiences were very different.

My family moved around a lot when I was a kid. By the time we settled down in Tampa, FL I had lived 4 different states, probably 6 or 7 different cities, and at least 6 different elementary schools. I was forced to get used to new environments and make new friends on a regular basis. While we had the basics, my family lived with a tremendous amount of financial insecurity.

My wife on the other hand grew up in one city her entire life. Her Dad was a mathemetician at Eglin Air Force Base, had one job, and she lived in one house until she went to college . Kimi grew up with a consistent set of friends and had all her family in the same general area. Her family was able to take a family vacation every year and didn’t have any of the financial instability I experienced as a kid.

While both families ended up just fine… my expectations about change very different from my wife’s expectations. My experience is that you do what you have to do, go where you have to go, and take chances and everything works out well. My wife’s experience is that you stay in one place, hold into what works, and don’t assume a bunch of risk and everything turns out well.

I could go on and on about other differences in our experiences growing up… relationships with parents and siblings… being the oldest or the youngest… the caliber of people we both chose to hang out with… our influences and our faith and the decisions we both made… but at this point I’ve already shared too much and don’t want to get into any more trouble than necessary to make my point

Needless to say people are complicated.

My point is this… as individuals, change isn’t really an intellectual process. It’s not really even just an emotional one… where if people could just see, or feel good about another way of doing things… they would get on board with the new approach. On many levels we are dealing with very personal deep seeded stuff… the stuff that anchors us as people and defines who we are in relation to the world.

I don’t know that I have any answers here… but I’ve been very intentional lately trying to understand more about the people I work with, who they are as people, their expectations about life and the world around them, and what makes them feel safe and secure in their experience with work. Sometimes you have direct access to that information, some times you have to infer it… but either way… it’s usually the truth behind the resistance.

Anyway… just something to think about. It’s an idea that’s been noodling around in my head for the past several months and this is my first attempt to put words around it. I’d be interested to hear what you have to share regarding this. I suspect it won’t be the last time this topic comes up.

Related Posts:

• Safety to Change
• 2010 in Retrospective: Mike Cottmeyer Edition
• Catching Everyone Up…
• Change is the only constant…
• 2008 in Retrospective: Mike Cottmeyer Edition

LeanKit and Focused Objective announced a partnership to provide customers with an integrated product offering. The combined solution will bring industry leading quantitative analysis to LeanKit’s and Focused Objective’s customer base in an easy to use and immediately available way. This analysis includes forecasting project delivery dates, pinpointing what factors such as staffing, quality, scope change, etc. are having the greatest impact on delivery dates, and the ability to find what staff skill additions will have the most impact. “The ability to answer tough questions relating to date, cost, staff and ...

JIRA is everywhere. Everyone talks about it, everybody wants it, but not everybody can have it – why is that? In my first article, I announced that a series of articles will follow in which Scrum tools will be reviewed. This blog entry is the first of many in which I will evaluate currently available Scrum tools that are able to represent a taskboard.

JIRA is a well-known issue tracking software developed and maintained by a company called Atlassian, that has a rich product portfolio in the field of software development, tracking and collaboration. Next to JIRA, Atlassian is also famous for its wiki software called Confluence. The following sections will focus on JIRA, especially on a plugin for JIRA called GreenHopper.

Functionality

JIRA is an issue tracking software tool and that is its greatest power. It has countless features and it can be stated without hesitation, that JIRA might be THE issue tracking software tool currently available on the market. While issue tracking is certainly a must have, one aspect that makes JIRA interesting especially for Scrum and Kanban teams is its plugin architecture. Currently, 400+ plugins are available. The one that catches our attention (and the most popular plugin right now) is called GreenHopper, that adds an Agile layer on top of the JIRA architecture. With GreenHopper, Scrum and Kanban teams can migrate their product backlog, their taskboard, their burndown charts and other Scrum artifacts to JIRA and create their electronic counterparts. Until recently, the functionality of GreenHopper was comparable to that of many other Scrum tools.

Since version 5.8, GreenHopper goes beyond that by introducing what they call a rapid board. A rapid board is a new approach to guide Scrum and Kanban teams through their corresponding processes. Therefore, two standard presets are available and a third one, which is called DIY where teams can alter processes in a manner that suit them best. In my case, I have chosen the Scrum preset. Before you can start creating your backlog, you have to link your new rapid board to an existing JIRA project – not very intuitive but understandable since JIRA itself is not Agile. After having done so, GreenHopper will present you an empty product backlog (what they call the plan mode), that wants to get filled with user stories. Lets fire up our keyboard and add some stories! By the way, GreenHopper offers you a choice out of five types (blocker, critical, major, minor, trivial) which you can assign to your stories / tasks. I will explain later on why that might be handy.

Did you enter enough stories to keep your team busy for the next sprint? Great, call them in, because right now, the stories needs to get estimated by clicking on each story and filling in the story points. As soon as all story points are entered, the team can choose an amount of stories to commit by simply dragging a sprint marker until they think it is enough. The sprint marker will then automatically show the total amount of committed story points and we can start the sprint by just clicking on the “Start Sprint” button; GreenHopper will automatically redirect us to our well-loved taskboard.

 

 

The work view (the taskboard) gives us a basic taskboard design, featuring the obligatory set of „To Do – In Progress – Done“ columns. Interestingly, the stories dont get an own column. Instead, they are placed in the „To Do“ column, with their corresponding tasks just beneath them. Wait – did I say tasks before we actually created them? Yep, and the reason for this is linked to a positive and at the same time negative aspect of JIRA: its flexibility. JIRA is highly flexible, you can alter it in each possible way that suits you best. But that flexibility comes at a cost: the interface is often not very intuitive – I will cover that aspect in one of the following sections. Back to creating a task: We have to click on the generated ID of JIRA (EVAPRO-8 if you look at my provided screenshot), followed by a click on „More Actions“ and then you are finally able to choose „Create Sub-Task“. After finding that somewhat hidden button, the process of creating tasks is much better, mainly due to the ability to leave the create task window open – very time saving when entering multiple tasks. Even more time saving is the ability to perform nearly all the commands by using keyboard shortcuts – your team will love it!

Yet another powerful feature of JIRA is its very own (SQL like) querying language called JQL, with which you are able to perform any search request you can think of. But there is more than just that – team members can customize their dashboard by using JQL so that they see what they want to see. Your team will love you even more!

Back to the columns of the taskboard. You might already have guessed it; it is also flexible and can be altered according to your needs, e.g. by adding a committed column which means that the PO can test the functionality and move the story/task to complete when it satisfies him or her.

JIRA can be used for multi project setups. In fact, you can use multiple projects as input for one rapid board. Interestingly, JIRA does not offer any more hierarchies beyond epic level (and it is rumored that even epics are just relabeled tasks). A plugin called „structure“ helps to create infinite levels of hierarchies, but it is third party and not perfectly embedded within JIRA and GreenHopper.

Still, JIRA is a feature monster: interfaces to other tools? Check. Archival / export functionality? Check. User access control? Check. Event-based notification? Check. Time registration? Check. Support for adding bug stories/tasks? Check. Assign tasks to people? Check. Undo functionality? Uncheck – no undo available, due to use of AJAX (see below).

Usability

When it comes to using JIRA with GreenHopper, the overall impression is twofold. On the one hand using JIRA without a mouse introduces a massive speed up of daily actions the team has to perform. On the other hand you get the feeling that GreenHopper, especially the rapid boards, did not leave beta status yet (which is clearly indicated by Atlassian. Rapid Boards are only available if you enable the „GreenHopper Labs“). Still, I would currently recommend enabling rapid boards, as they make the whole Scrum process more enjoyable.

Atlassian should also try to be more consistent when it comes to naming functionality. When you start the normal planning board, GreenHopper will present you a „New Card“ button. For me as a user it is immediately clear that I can add new user stories by clicking on that button, as user stories are normally written on cards. When using a rapid board, this button is not available anymore. Instead, a much smaller and more hidden „Create issue“ link is presented. Even more confusing, in planning mode the „New Card“ *and* the „Create Issue“ links are available, both offering a completely different interface experience. Where „New Card“ is the much simpler, Scrum-related one, „Create issue“ is the JIRA standard interface, that is much more complex. In the end, it does not matter which interface I use to add a new story – but it is confusing.

Briefly touched in the previous section, it is also not very intuitive that one has to create a JIRA project before using GreenHopper. The same is true for adding a task to a story, which requires way too many clicks. Of course, you can change that interface to make the „Create Sub-Task“ link more visible, but that involves lots of unnecessary work for a feature that should be available by default.

Performance

Performance-wise there is not much to say, JIRA performs quite well. Ok, to be more elaborate: JIRA works much smoother than other tools if the bandwidth available is low. In fact, I have tested JIRA and GreenHopper by setting up my smartphone as a hotspot and the experience is great. One of the reasons for that experience is, that especially GreenHopper (JIRA itself much less) make extensive use of AJAX functionality (where AJAX simplified means that the browser does not have to refresh the whole page when changing an option or clicking a button). As testing platform I have used Atlassians very own cloud service, and I never experienced any downtime nor hiccup. Does this mean that the cloud can be classified as highly-available? Of course not, but exploring that is outside the scope of this article.

Resources

GreenHopper does not require a client software to be installed on each of the team‘s machines since it runs within a web browser, which is standard nowadays. Atlassian claims that JIRA and GreenHopper work on each browser as long as you browser version is high enough. From my point of view, those versions are not cutting edge, so chances are high that it works within your company’s IT landscape. Screen wise, XGA resolution is required (1024 x 768 pixels) – any moderately modern screen should fulfill that. However, there is one barrier that might come at a cost. The current GreenHopper Version (5.9.X) requires atleast JIRA version 5.X – a JIRA version most of the companies will not have running right now. Although GreenHopper (til 5.8.X) does work with JIRA 4.4.X, the much praised rapid Boards were introduced in this very version – chances are high that those boards might be buggy when using GreenHopper 5.8.X.

Interface

Some aspects were already mentioned, nevertheless the interface is much better as one might expect after reading the usability section. First of all, the rapid entry of new stories and task is a big plus, thanks to the large amount of keyboard shortcuts and the possibility to leave the „New Task/Story“ window open after adding a task or a story. Another great aspect is the highly flexible and sophisticated user dashboard. Each team member can change the content he or she wants to see on his dashboard by arranging the available components or by adding a new component, using JQL.

One of these available components is the so-called Activity stream which offers a similar experience as Facebook‘s News-Feed. New Stories/Tasks but also changed states of issues are displayed, each of those items offer the possibility to leave a comment or to add it to the users watch list if he or she wants to track any upcoming changes. Next to its dashboard, the user can also configure the taskboard in such a way as it pleases him or her. For example, he or she can choose to show only recently updated tasks, tasks of high importance or self-assigned tasks. By doing so, GreenHopper allows the user to create an interface that suits his or her needs.

Again, the possibilities of GreenHopper do not stop here. A fullscreen mode is also supported, the same is true for high contrast figures (using the wallboard plugin). Drag & drop is of course also available for moving tasks or stories and last but not least, the website is designed in such a minimal way that its layout does not waste space horizontally or vertically. Although the design looks simple, it is created in a way that enables the use all that flexibility JIRA and its plugins provides.

Motivation

Motivation is and was always the trump card of paper-based taskboards. Only they were able to provide a certain haptic feeling. A feeling, software is not able to give. Unsurprisingly, this is also true for JIRA with GreenHopper. However, Atlassian comes quite close by offering numerous high contrast figures, using the aforementioned wallboard plugin. Recently, a Minecraft Plugin has emerged which offers gamers an innovative new way of solving JIRA issues.

Costs

JIRA and GreenHopper are available as download for installing it on your company‘s dedicated hardware and as on-demand, which basically means that Atlassian hosts JIRA including GreenHopper for you on their server farm. Which option you choose is of course up to you, although most of the companies will favor the first option due to security policies. The minimum fee is 10$ – either as a one time purchase when you want to deploy it on your own server (10 users, the money will be donated to charity(!)) or 10$ a month, if you want to run it on-demand (again 10 users). According to Forrester, JIRA is by far the cheapest option of the Top 10 vendors of Agile Software – twice as cheap than the second cheapest vendor and just 18 times cheaper than the most expensive vendor. That is quite a number. And if one compares the offered functionality with other vendors it becomes clear why JIRA rightfully claims being a rising star.

Advantages

1. Flexibility
2. Costs
3. Own query language

Disadvantages

1. Inconsistency
2. Beta-feeling of rapid boards
3. Flexibility

The curtain falls

This was the first article that evaluates JIRA’s abilities to represent a taskboard. Next time I will evaluate  ThoughtWorks Studios Mingle.

References

West, D., Hammond, J.S., The Forrester Wave: Agile Development Management Tools, Q2 2010, Forrester Research Inc.

May the 11th I participated to the #Agilmente conference organized by the PMI NIC in Portonovo (a wonderful place at the mediterranean sea), in collaboration with club ti Marche (@clubtimarche) and Controller Associati Ancona. In that occasion I had also the pleasure to give a talk named “Agile project management: a trade-off between pro-activity and re-activity“. [...]

Once you have a program (a collection of interrelated projects focused on one business goal) and you have technical debt, you have a much bigger problem. Not just because the technical debt is likely bigger. Not just because you have more people. But because you also geographically distributed teams, and those teams are almost always separated by function and time zone.

So, my nice example of a collocated team in Thoughts on Infrastructure, Technical Debt, and Automated Test Framework, rarely occurs in a program, unless you have cross-functional teams collocated in a program. If they do, great. You know what to do.

But let’s assume you don’t have them. Let’s assume you have what I see in my consulting practice: an architecture group in one location, or an architect in one location and architects around the world; developers and “their” testers in multiple time zones; product owners separated from their developers and testers. The program is called agile because the program is working in iterations. And, because it’s a program, the software pre-existed the existence of the agile transition in the organization, so you have legacy technical debt up the wazoo (the technical term). What do you do?

Let’s walk through an example, and see how it might work. Here’s a story which is a composite from several clients; no clients were harmed in the telling of this story.

Let’s also assume you are working on release 5.0 of a custom email client. Release 4 was the previous release. Release 4 had trouble. It was late by 6 months and quite buggy. Someone sold agile as the way to make software bug-free and on-time.

You do not have automated tests for much of the code, unit tests or system tests. You have a list of defects that make Jack the Ripper’s list of killings look like child’s play. But agile is your silver bullet.

The program manager is based in London. The testers for the entire program are in Bangalore because management had previously fired all the testers and outsourced the testers. That was back in release 2. They have since hired all the Bangalore testers as employees of the Bangalore subsidiary. The program architect is based in San Francisco, and there is an architect team that is dispersed into 4 other teams: Denver, LA, Munich, and Paris. The developers are clustered in “Development Centers of Excellence:” Denver, LA, Cambridge, Paris, London, Munich, and Milan. That’s 8 development teams.

Oh, and if you think I’m kidding with this scenario, I’m not. This is what most of my clients with geographically distributed teams and programs face on a daily basis. They deserve your sympathy and empathy. Do not tell them, “Don’t go agile.” That’s nuts. They have a right to go agile. You can tell them, “Don’t go Scrum.” That’s reasonable. Scrum is for a cross-functional co-located team. Agile is for everyone. Scrum is for a specific subset.

What do you do?

1. Assign specific testers to specific development teams. No calling people resources; that allows managers to treat people like resources and plug-and-play them. You need to get rock-solid teams together. Once you have teams together, you can name them.
2. Name teams so the teams reflect the feature groups they work on. What does an email product do? It gets email, it sorts email, it deletes, it forwards, it creates new mailboxes, and so on. The eight feature teams had to be named for the feature areas: Platform for the general features, Sort, Delete, Forward. There were two teams who worked on Platform. They were called Platform 1 and Platform 2. At one point, someone suggested they call themselves Thing1 and Thing2 from the Dr. Seuss book.
3. Make sure you have enough product owners so they can develop roadmaps for each feature area. With a roadmap, the teams know where they are going. Even more importantly, the architects know where the program is going.
4. Architects think and provide just enough guidance ahead. In a small project, the architecture can probably evolve with the project. In a larger program, that risk is too large. You have too many people developing in parallel for the architecture to evolve on its own with no guidance. But I do not mean there should a Master Architect Who Knows All Handing Down the Architecture From On High. NO NO NO.
   I want the architect who is a working member of the development team, who also is part of an architecture community of practice team, who curates the architecture, who guides the business value of the architecture. I do not want Big Architecture Up Front. But Thinking Up Front? Sure, that’s a great idea. Stuck on only one idea? Bad. Willing to spike an idea? Great. Willing to play in a sandbox and debate several ideas? Great. I wrote about this before, in How Agile Architects Lead.
5. Decide what done means for every feature. You must have acceptance criteria for each feature. What does that mean? You need a product owner present for each team. You still need the conversations with each team to discuss what done means. Especially with a geographically distributed team, you need the conversation when you create the backlog at the beginning of the iteration.
6. The US  development teams had trouble planning their iterations with their testers, because of the time zone differences with the testers. So, they asked their product owners if the product owner would write more than just a few phrases on the cards, because that would help them get through the iteration planning meeting faster. Someone was going to get up early or stay up late, and either way, someone was going to suffer. It made more sense to have a little bit more preparation than less sleep.
7. Decide to do continuous integration and stick with it. Especially if you know you have technical debt and you don’t want to create more, you have to do continuous integration now. That prevents more technical debt.
8. I have recommended to some teams that they have one-week iterations so that they stop the estimation nonsense and make their stories small. The point of estimation is so that you have an idea of what you can do as a team and not commit to more than that. The idea is that if you know what it takes to make your stories small, you will.
   Instead, we have all these crazy rituals around estimation and management tracking velocity of all things. (Yes, I’ve been drafting this post for a long time, and I wrote Why Does Management Care About Velocity? last week.) You know, velocity is a little like weight. Only you and your doctor need to know your weight. If you are healthy, you are fine. If you are not, you need to change something.If your team velocity is not healthy, you, as a team, need to change it. But, your management has no business butting its head in. Only you can change it.
9. When you limit the iteration length, you tend to have the team swarm around a story. This is a tendency, not a given. If I really was the Empress of the Universe, I would decree this, but I’m not, so I won’t. If you want to decrease technical debt, or even eliminate it on your program, explain that your team will only work on one story at a time until that story is done. That story will be polished and gleaming. Fast. You will not have to worry about what kinds of testing will be done. All if it will be done.
10. Explicitly discuss what you will automate for testing and when. In a program, I assume we will have automated system tests first. I assume we will do exploratory tests later. That’s because if you don’t start building something for test automation when you start the program and refactor as you proceed, you can never catch up. I assume every time we fix a defect, we will have an automated test for it. I also assume we build these assumptions into how we develop :-)

So far, this is all about preventing more technical debt, not what happens when you trip over technical debt as you enter code or tests you never looked at before.

If you expected to walk into a closet, take out a shirt, and close the closet door, that’s one thing. But now, you stepped into something out of one of those death-by-hoarding shows on TV, you have an obligation to do something. You can document the problem as you encounter it; you can let the product owner know; file a defect report; write a test so you can contain the debt; and maybe you have more options. Whatever you do, make sure you have done something. Do not open the door, see the mess inside and close the door on the mess. It’s tempting. Oh my, it is tempting.

See, on programs because of the size, everything is magnified. With more people and more teams, everything is harder. Things happen faster. If you have co-located cross-functional teams, no problem. But if you don’t have co-located cross-functional teams, you have to work with what you have. And, if you already have a big legacy product, you want to address technical debt in small chunks, refactoring in small bits, integrating as you proceed.

My philosophy is this: the bigger the program, the more you need to become accustomed to working in small chunks, integrating as you go. Fully implement a small story, integrate it on the mainline. Everyone on the program does that. If you need help from an integration team, so be it.

But, if everyone only implements small stories, and everyone takes care of their own technical debt as they discover it, you don’t need an army of integration people. You only need an army of integration people when you have technical debt around integration and release. Fix that, and everyone can become responsible for their own integration.

And, if you can’t release, that’s where the architects should start. If you can’t do continuous integration, that’s where the architects should start. Because that’s what’s preventing you from making progress on the product. Work backwards from release, and then the architects can work on the rest of the product. Until you can release and build reliably, the rest of the product doesn’t matter.

After the much-anticipated release of Google Drive, there have been many articles about teams using it for project related collaboration.  With Assembla’s Google integrations, using Google Drive in combination with Assembla results in the ultimate collaboration powerhouse.  

The integration allows team members to link to their Google Drive files from tickets, wiki pages, messages, etc. without having to manually share files though Google’s web interface. No matter what type of Google Drive file, team members will always have instant access because Assembla "shares" the document when a team member clicks on it.

How does it work?:

From within multiple tools of your Assembla Project Workspace, you have the option of attaching a local file or attaching a Google Doc.  For example, you may want to attach a Google Doc to a task.

When you click on the upload a Google Doc option for the first time, you will be taken to a Google page to grant Assembla access to your files – it’s safe and secure.  Once you grant access, you will get a Google file picker pop-up that displays all the files on your Google Drive.

When a file is selected, our integration automatically grants instant access to anyone that is a part of your Assembla team so you don’t have to individually share anything.

Working with Google formats (.gdoc, .gsheet, etc.):

Google formatted documents and spreedsheets are ideal for content and requirements collaboration because of their ability to have multiple contributors working on the same web based file.

For example, the marketing team at Assembla is responsible for a lot of content creation and collaboration tasks. Every ticket/task has a Google Doc attached to it where the content comes alive from multiple contributors though drafts, edits, comments, etc. until it is satisfactory. Passing around and uploading new versions would double the time required to complete these tasks.

Working with other file types from your Google Drive:

Google Docs is nothing new but Google Drive adds many new capabilities. With desktop integration, you can now easily add any file to your Google Drive. When you work on the files locally, new versions are synced to the web-based drive.

Attaching these files via “Add a Google Doc” integration is different than just attaching the files via “Add a File” from your computer because they are accessed from Google’s version and not the version you attach. This is better because:

• When you attach a file from your Google Drive, you can still work on it locally without having to attach an updated version – the Assrmbla link is always the most recently synced version from your computer.

• These files are accessed directly from Google and not Assembla so you do not have to upload anything. Attach a 100 mb photoshop file or a 1 gb video file and it is instantly available without waiting on uploads.

Assembla’s Google integration is perfect for teams that are using or considering Google Drive but also require a complete suite of integrated collaboration and development tools like tickets, code repositories, deploy tools, wikis, messages, and more. 

How many middle managers and agile coaches have asked themselves this question: Why is the C-Suite clueless? We try so hard to get their attention, but they just won't listen.  I think I am connecting the dots on why they don't listen.

Overwork is surely part of the problem, but it's deeper than that. Management has always been accustomed to communication by broadcast; listening and reacting have not been its strong suit. Before globalization, that wasn't much of a problem, because the customer didn't have many alternatives. But today, customers can easily go elsewhere, the complexity has risen, and the job of management has gotten much harder.

Today, I believe Management is in denial. It is in denial because it is being told by the marketplace: "you suck." Management focuses on improving the quarterly results, lowering the cost, and with it the quality to the point where lemonade doesn't have any lemon juice in it. And then they wonder why people chose to buy elsewhere.

Denial is a grief response, a normal response to bad news that you cannot change. You don't like the message, so you try to ignore it, until the message is so strong, like a lost lawsuit or impending doom, that it cannot be ignored.

Today, management needs to get out of denial and get on with fixing what's broken. An interesting case came to light at the Scrum Gathering in Atlanta: Domino's Pizza.

Domino's Pizza was (and is again) a successful fast food chain. They became famous for delivering you a pizza within 30 minutes. 10 years after being sold to a holding company, they had fallen to last place in customer approval ratings and were threatened with extinction. Their crust "tasted like cardboard" and the sauce "like ketchup." Their share price hit a low of $3/share. Whether management noticed what their pizza tasted like is unclear, but they did notice their share price: they had come to the brink of disaster and realized that they had change. So step 1 was to admit that "we suck" and step two was to do something about it (watch this 4 minute video to see this in action):


What did they do? They created a clear line of sight from all levels of the the organization to the customer. They reacted by listening to their customers and creating products that were dramatically better than before. They admitted their mistakes in public and promised to get better. They did it quickly.

They were successful. I stopped by Domino's at ATL Atlanta Airport and found the pizza to be quite OK. (OK, it's still fast food. The Pizza DOC at Molino Frascati in Zurich is still among the greatest pizza I've ever had, followed closely by the pizza at Northlake Tavern in Seattle's U-District, but that's like comparing F1 racers to anything off the production line.) In any case, their stock price has also more than recovered, having just set a 7 year high around $40.

So if your organization is having problems, how can you fix it?

1. Admit that you suck. Once you've admitted it, you can move on and start getting better. 
2. Recognize that you and everyone in your organization is doing a good job. The best they can, under the circumstances. This isn't about blame, it's about getting better.
3. Do something about it! Start right away.

What should you do for step 3? That depends! Here are some places to start:

1. Within your management team figure out what your priorities are and what they should be. Radical Management can help here. So can a Temenos Retreat.
2. Understand what your customers are telling you: Create a clear line of sight to your customers at all levels of the organization.
3. Start implementing improvement immediately. Figure out what your biggest impediments are to customer satisfaction and start fixing them. Scrum can help here, even if you are not doing IT.

Many years ago, Ken Schwaber, the co-inventor of Scrum, became famous for telling people, especially top management, 'You suck, and that makes me sad.' It's a challenge to get better. It's a challenge, but you can do it if you want to.

People interested in agile development gathered from all across the Northwest (Beaverton, Gresham, Hillsboro, King City) to attend AgilePalooza Portland last month.

The attendees were eager to get started. An exceptional collection of agile development experts were poised to share knowledge, excite, inspire and persuade.

After sharing logistics and speaker introductions, it was time to get out of the way and let the learning begin.

Before the stage was yielded to the keynote speaker, Santeon Group’s Ahmed Sidky, I asked the Portland audience a question:

“How many in the audience had participated in an Open Space?”

The Portland Agile Community was eager to participate in Open Space.

A stark silence gripped the room as two lonely hands reached up.

With the Open Space comprising the entire afternoon schedule, I was concerned:

• Would the attendees all leave after lunch?
• Would a lack of familiarity hinder the effectiveness of the Open Space sessions?
• Would the morning session feedback be negatively impacted by the inexperienced ‘Open Spacers?’

The morning prepared speech portion of AgilePalooza Portland began to be delivered. Ahmed Sidky, Diana Larsen, Dave Sharrock, Michael Tardiff and Steve Ropa connected effectively with the eager minds who had taken time out of their busy lives to learn agile for the first time or to ‘sharpen the saw.’

As the attendees finished lunch, we put the finishing touches on the Open Space preparations and gave control of the event to Diana Larsen, the Open Space facilitator for AgilePalooza Portland.

While Diana Larsen briefed the group about Open Space, I glanced around the room and observed one thing:  a full house!! The inexperienced ‘Open Spacers’ were willing to give it a shot. And I am glad they did.

The topics were selected and the discussions spread freely and easily:

• Testing in agile
• Where do technical writers fit in the world of agile?
• ScrumMaster struggles

For the next two-and-a-half hours, project managers, developers, testers, development directors and product managers learned, pushed, pulled and debated the issues that mattered to them most.

A beginner ScrumMaster asked, “How do I get better engagement for the Scrum Team?”

An even more inexperienced ScrumMaster gave a suggestion that was insightful and gave the questioner just what she wanted…

Try the Temperature Reading game or ‘strongly encourage’ all Retrospective attendees to place a sticky note on the wall that cites ‘what went well?’ and one sticky note that cites ‘what can we do better?’

It was a great AgilePalooza Portland and a buzz-worthy Open Space. Thanks to the Portland community for embracing the event and expanding the collaborative power of Open Space.

Dan Naden
VersionOne

Typically, when an organization starts using Scrum, the person chosen to play the role of ScrumMaster comes from some sort of managerial background. The organization expects that the manager, the so-called Master, will get the Scrum project deli...

Agile processes are gaining in popularity, which means many project managers are following them for the first time. Based on my own experience, I've developed a sort of primer for PMs starting out on Agile projects. The key points are as follows: ...

The Influencers Mantra:

Mantra (n): A word or group of words, an act or a series of acts – all considered capable of creating “transformation”.

(“man” – mind + “tra” – liberation).

My good friend Siraj Sirajuddin is hosting his workshop “The Influencers Mantra” at the VersionOne offices in Alpharetta, GA on June 7, 2012.

While I haven’t had the opportunity to attend this workshop personally, I’ve had the pleasure of getting to know Siraj over the past several years, and find him very wise and full of great advice and practical guidance.  I’m trying  really hard to keep the date open so I can attend myself… I think it will be that valuable.  So… if you happen to be within driving distance of Atlanta and want to learn more about the human side of transformation, I think this will be a really good use of your time.  At $425/$525 it’s also an excellent value for a day of high-end training.

For more information, or to register for the course, check out Siraj’s site at http://blog.siraju.com/

Related Posts:

• Cool Agile Stuff in Atlanta… In September
• InfoQ Interview with Mike Cottmeyer – Agile Adoption and Transformation
• VersionOne AgileLIVE Webinar Series: Blending Scrum and Kanban to Create an End-to-End Agile Enterprise
• InfoQ Sessions from LeanSSC 2010
• Product Owner Team Design Considerations

Diana has written previously about the Human Systems Dynamics Institute and their excellent program that provides models and methods for dealing with our VUCA (volatile, uncertain, complex, ambiguous) world of complex adaptive human systems. In this post she focuses on the HSD Adaptive Action model and its unexpected connection to retrospectives:

In 2006 Esther and I introduced a Flexible Framework for Agile Retrospectives, a series of stages for designing effective retrospectives: Set the Stage; Gather Data; Generate Insights; Decide What to Do; and Close the Retrospective. We recommended a recurring cycle of retrospectives after each iteration as a process for the team to “reflect, tune and adjust”, as the Agile Manifesto principle decrees.

While a defined opening and closing belong in any effectively facilitated meeting, what happens in between looks very much like HSD’s Adaptive Action cycle. Put simply, it goes like this: What? So What? Now What?

“Adaptive Action provides an iterative process of seeing the patterns in the environment, planning for change, and the re-scanning the environment to see what is needed next. Adaptive Action can be used to bring about both short-term, operational, day-to-day change and longer term improvements. It is a process that can be used at any level of the organization at any time…All it requires is a commitment to improvement based on data from the environment and the willingness to review progress continuously.” - Royce Holladay and Kristine Quade, Influencing Patterns for Change: A Human Systems Dynamics Primer for Leaders.

HSD provides group activities for understanding complex adaptive human systems that fit the purpose of each part of the model.

An example:
In “What?” a retrospective facilitator shows the team how to describe its environment in terms of Containers, Differences, and Exchanges (CDE conditions for self-organizing) or guides team members to brainstorm the ways this iteration was the Same and Different from previous ones. The team asks questions, collects data, and observes patterns. They ask “What just happened or is happening now with regard to the focus of this retrospective?”

In “So What?”, the team looks for patterns and analyzes how those patterns influence their work or examines the Generative STAR model to identify areas of strengths and challenges or reflect on the implications of differences in Decision Map models between the team and its customers. They seek to understand what is important about the “what,” they analyze the data, and make meaning of it. They ask, “What patterns help us? How could we shift patterns that don’t help us? What CDEs exist, and how can we move them to create different patterns?”

In “Now What?”, the team chooses one adaptive action to implement in the next iteration. While implementing it, team members observe the new patterns that emerge, and collect new data to bring to the next retrospective.

Adaptive Action iterates, pays attention to patterns, flexes to accommodate new data, sees many dimensions, and relies on fast cycles.

“Using an iterative cycle of ‘What?’ ‘So What?’ ‘Now What?’ helps planning (for continuous improvement) move progressively forward.” - Holladay and Quade

And Now What?
If you’re interested in learning more about the HSD program and/or the models and methods for working in complex adaptive human systems during complex times, check out the website for resources, upcoming events, and links to webinars.

College Roomate: So you know vi?
Me: Of course, that would be command shift-Z-Z

This is a conversation I had about twenty years ago. For most of my Unix editing I got by with pico and I found the modal nature of vi downright frustrating. Hence the importance of knowing the command to escape from modal hell.

At my current company vim was the default text editor, I even paired in the interview on vim. Over the years I’ve bounced between text editors and IDEs depending on the languages and environments. One key point though was that when I reached for a text editor it was always one with a GUI front end like BBEdit or TextMate. Despite working in vim most of the day I still default to MarsEdit for writing blog posts.

I jumped into vim with some lingering fear remembering my dislike of its modal nature and the lack of any mouse support. I tried out VimGolf and spent some time trying to memorize basic navigation and selection commands. It came pretty slowly at first. I bogged down my pair quite a bit fumbling around with arrow keys or splitting the screen the wrong way. About two months in I had developed some basic proficiency, but I found myself wondering if RubyMine or TextMate wouldn’t be a better option.

At about the 6 month mark I looked back and realized I was finally comfortable in vim as I found myself defaulting to it for most of my text editing even when I wasn’t working on code. I still have a few cases where I prefer using a visual editor or IDE for tasks like:

• blogging
• email
• exploring large projects
• larger refactorings

Looking back there were several items that accelerated my vim mastery. One was our switch to sharing a single base .vimrc so when you pairing with anyone you had the same configuration of the editor. It also included several features like macros for commenting, formatting, auto-complete, and running inline RSpec. After setting up that .vimrc I saw how vim could be a more powerful tool.

Another big step was learning to love ‘hjkl’ over the arrow keys. That took about a week or so to break the habit and it was painful, but the speed difference was worth it. The mouse is already gone, so might as well toss the throwback to the arrow keys. (I found the hack here on Stack Overflow.)

A critical change that I arrived at fairly late was remapping my caps lock. Normally you rarely touch caps lock, but it is in a very convent position especially compared to the escape key. I remapped my caps lock to tap it to get an escape and holding it down yields a control which are the two most commonly used modifier keys in vim. That made my fingers very happy.

Finally, the biggest learning expeditor was pairing with a number of developers who had more expertise than myself. Since the team had standardized on vim before I arrived they had all gone far past where I was on the learning curve and were able to quickly demonstrate how to use vim or which keystroke to use as I fumbled along. I greatly appreciated their patience and willingness to let me bang something out that they could have typed in half the time.

I still don’t feel anything like a vim expert, but I do feel comfortable in a modal editor. Never thought I would be typing those words all these years later.

Trac is an open source enhanced wiki and issue tracking system for software development projects. Trac uses a minimalist approach to web-based software project management. It provides an interface to version control systems (Subversion, Git, Mercurial, …), an integrated Wiki and convenient reporting facilities. As many open source project, Trac has a plugin architecture that allows to extend the core functionalities. Here is a list of Scrum and Agile oriented plugins available in the Trac ecosystem. Trac is build with Python and can run on various Linux distributions, Mac OS ...

Matthew Evans shares with us an Excel spreadsheet that allows to record and visualize informations about your Scrum sprint. One sheet allows to manage the sprint data with the estimated and actual work for each story. A project page consolidate the sprints data at a project level.  Visit the “Agile scrum project management spreadsheet” page to get the spreadsheet.

In my last post I made my case for describing organizations in terms of communication structures. Persons that are interacting much with each other should be in one cluster within the organization. Bridges between clusters are needed and are created by communication paths between at least one member of each cluster.  By crossing multiple bridges everyone will be connected to most other people in the organization.
Let’s imagine in the situation above the organization is distributed across different locations and the teams each develop software based on a shared data base but with different purpose. Due to some performance issues, Team 1 needs to change the DB schema for some of the data. They communicate this to their PO who in turn lets the PO team know about the need to change the schema. One of the POs realizes the impact it will probably have on his team and informs them about.  This is the red path in the picture above. However, such communication paths are not a good idea if they become too long. Too much noise on the way will distort the message and even if the message arrives intact, it will arrive with a delay. To remedy this, shortcuts must be introduced to get more direct communication going.

In other words, the teams should talk directly to one another. But simply drawing such a shortcut in an organizational chart is not going to make the communication happen. Since the teams in our example have little common ground save for the underlying data base, which has been stable for long, they do not know much about each other. Team 1 does not know which team will be impacted by their changes. It is necessary to identify what the content of the communication is that needs to take place in a more direct form. Does it happen frequently that such messages have to take a long way to reach the proper recipient?  In our example the question would be, how often the organization has data base issues that need to be coordinated across teams. In many cases the people involved notice the need for more direct communication and self-organize into virtual teams with the same special interest.  In other cases it needs a good leader to identify the missing communication link and help the members of the organization to establish such special interest groups.  The very appropriate nom-du-jour for these groups is communities of practice. Maybe a community of practice (CoP) for DB administration would be appropriate in the example. Such a CoP should have a member from each team that uses the data base in question. They organize themselves, meet on demand or regularly, face-to-face or virtually, set standards pertaining to their topic, make decisions about changes, etc. They communicate directly and do not have to rely on messaging through other persons, particularly not their line managers…

And yet again – there are no managers in the organizational chart. Do we need them at all?  If so, where do they fit into the picture? Watch this space for answers to this and other world shattering questions.

 

Christof Braun, Trainer Management 3.0 & Management Consultant

Related posts:

1. Software Architecture is a Social Activity! Conways Law
2. ScrumMaster and Domainleads – our solution for large organizations
3. 5 min on Scrum | How to do Scrum Scaling with international teams?