Customer service agents battle on the front-lines daily. Whether they’re taking inbound calls, answering emails, or juggling chats, it’s pretty important we find a way to make their lives easier (we want them to heart our customers right?).
Axosoft HelpDesk is an awesome, approachable solution to your customer support needs. It has the ability to convert support emails into tickets, manage those tickets, and it comes with a handy customer portal. These three capabilities will equip your team to assist customers fighting the good fight out in the field.
Much like a violinist trying to learn viola, if you’re a user of Axosoft Scrum or Axosoft Bug Tracker then you’ll find yourself serenading away with our Axosoft HelpDesk. Ticket management behaves identically to defect or feature management, which means you can customize their fields, workflows and filters the same way you have in our other products. We highly suggest you try color coding your tickets to make them more pleasing and discerning to the eye. Check out this link to learn more.
Email integration allows all your emails to come into our system as tickets, and is by far the most distinguishing feature of Axosoft HelpDesk (which is getting some love in our upcoming 14.2 release).
Once you set up all the email connections (IMAP or POP3), the system will check the email account every few minutes and pull in new emails as new incidents. That way, everything comes into one central location where your entire team can access and manage the following:
Move tickets through the workflow
Send outbound emails
Keep a history of emails within each ticket
You can even set up auto-replies and gain access to more advanced settings. If you need help enabling any of these features, check out our documentation.
Axosoft HelpDesk’s Customer Portal is a simple, easy-to-use ticketing system. It allows any customers you have defined in the system to login, create tickets, and potentially monitor their ticket’s progress.
This is where things start to get interesting. You see, the best part about Axosoft HelpDesk is its ability to integrate seamlessly with Axosoft Scrum, Bug Tracker and Wiki. You can choose to expose parts of your Product Backlog, Defect Backlog and Team Wiki via the customer portal.
Want customers or internal employees to log a bug? Use the Customer Portal.
Want a place for feature request submission? Use the Customer Portal.
Want customers or employees to access and edit project wiki pages? Use the Customer Portal.
You start to get the picture. Check out our customer portal documentation to learn about how you can get this set up. By the way, this Axosoft HelpDesk synergy with Axosoft Scrum and Axosoft Bug Tracker also works with email. That means yes, you can also have folks email bugs or feature requests into your backlogs as well.
Axosoft Help Desk shines when combined with Axosoft’s project management and bug tracking solutions. If you’re considering trying the product, you can start a free trial today to see what you think. If you’re a current customer, you can also request a trial of Axosoft HelpDesk by going to Tools > Account Administration > Modify Plan.
There is so much more to Axosoft HelpDesk, so expect even more related blog posts in the future. ‘Til then, may the Support be with you!
At the Better Software/Agile Development conference a couple of weeks ago, I gave a talk entitled At Least Five Tips for Improving Your Geographically Distributed Agile Team. (That link goes to the slideshare.)
If you look at Scott Ambler’s 2011 survey, you can see that his data matches my consulting experience. About half of all agile teams have at least one person not co-located. This is by management design.
We can say, “don’t do this,” but that’s not helpful to the distributed and dispersed teams. I would rather be helpful.
For example, in my talk, not the slideshare, I actually said, “Don’t do standups. Do handoffs.” If you are more than about 4 or 5 hours apart in timezones, standups make little sense. You are better off limiting WIP (with a kanban board) than using straight Scrum. Yes, use iterations if you like. You might like the focus of the timebox. But, consider using handoffs, not standups. Change your questions to statements—if that works for you. Change your deliverables to fit your needs.
One tip that created a ton of discussion was the one about keeping people together over time. Some managers are trying to be “efficient” about using team members, optimizing at the lowest possible level. They move people off and on teams, willy-nilly. (Groan.) I explained that agile is about finishing features, so their best bet was to optimize at the project level, or the project portfolio level. It didn’t matter if people weren’t fully utilized. People were best utilized when they asked, “How can I help move this feature across the board?” In a geographically distributed team, that is sometimes a difficult question to answer, especially if the testers are east of the developers.
I had stories, and we had audience participation, which is why the slides are sparse. I hope you enjoy the slideshare. If you have questions, please ask away in the comments. I will answer.
On Wednesday, June 18th, we will be supporting our friends in the Jenkins and CD communities at the Jenkins User Conference in Boston. See you there.
We use Jenkins heavily here at Assembla, and we provide a number of integrations. Here are some blog articles.Fun with Jenkins
Some things we do with Jenkins:
Jenkins oAuth plugin enables jenkins to access Assembla API without giving up user credentials to Jenkins. https://public.assembla.com/code/assembla-oss/git/nodes
Jenkins Assembla Merge Request builder - https://public.assembla.com/code/assembla-oss/git-2/nodes - lets you automatically generate Jenkins jobs for new merge requests in a specified repository, using templates to create the jobs. It constantly polling Assembla API and in case of new Merge Request detected, plugin creates new build-job.
Run Jenkins under an Assembla tab. At Assembla we have custom tool tabs, where our jenkins lives. Using oauth jenkins plugin + Assembla API, we allow our developers to authenticate on jenkins, right in place without leaving our private development space.
Use Jenkins for Continuous Delivery at Assembla, with an amazing build process so that we can test and release every change, independently. All development is done in private developers forks, in branches. After developer pushes to the remote branch, and create merge request from branch to upstream master, jenkins automatically picks up this change.
- It runs a test suite. So, every change can be tested by a computer before it is reviewed by a human.
- It automatically deploys from given branch to newly created EC2 amazon instance. This gives our QA and product managers an easy way to find and test the change.
After QA or product owners look at the staged branch, we proceed to production deploy. The system merges to upstream master and deploy actual code to production.
After the merge, Jenkins automatically cleans up. It removes jobs, builds and EC2 instance.
I advocate widening product ownership to a team.
- A Product Owner’s Syllabus | by Olga Kouzina http://t.co/RvJNU0bO5v
- Why bother? – Using an Opportunity Canvas to drive early feature discussions | Agile Product Discovery http://t.co/ljblUdLFuk
- How to build features people will want | by Lynne Cazaly http://t.co/MoFVj0XtoT
- The GO Product Roadmap | by Roman Pichler http://t.co/YIREsgN9Hj
- 12 Tips for Product Owners who want better performance from their Scrum Teams | Saat Network GmbH http://t.co/z7DmhyMiZr
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading! Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
If you’re in a particular Agile crowd, “certification” is a dirty word.
On the other hand, the Human Resources/People department in your organization looks for certifications on your resume, asks about them in job interviews, and you may get promoted or better compensated party through the accumulation of certifications. Getting “certified” as a user of a tool, or as a signal of skill acquisition may give you a personal boost as well.
So, what’s with the dirty word? What’s not to like about certification?
We think anyone can agree that having the piece of paper may not accurately reflect your skillset.
The Agile Alliance opinion on the matter is that certifications should be skill-based, difficult to achieve, and not a primary reason to hire.
So in this storm of differing opinions about the upsides, downsides, and current realities about certification. It’s easy to forget the most important missing elements.
- Where am I on my Agile skill journey?
- What have I just mastered?
- What skill do I need to work on next?
Without this fundamental guiding compass, of “where have we come from?” and “where do we need to go next?”, Agile teams stagnate, founder, and drown in the swamp of opinions, skills, practices, philosophies, and so on, that comprise the current state of Agile.
Point being, if “Agile done well” was simple, we wouldn’t be having this conversation. Anybody could do it. No problem.
By having the conversation, we can simplify the complex and create a compass for navigating the swamp.
Even better, as more of us make it through, we begin to beat a series of paths through the swamp that work for most teams most of the time, leaving the Agile landscape better than we found it. Safer. More fun. More “this is the best job I’ve ever had.” More able to deliver value.
In five years, the Agile landscape may look more like a garden than a swamp.
When you attend the Agile Fluency™ Project workshop, we won’t certify you, but you will become intimately familiar with the Agile Fluency model and the best of good practices. The model will empower you to evaluate your team and the teams of others according to their behaviors and the results they achieve. You will know just where you are coming from, where you need to go next, and the investment in skills and gear to navigate the swamp. You’ll be able to help other teams find the same knowledge. And the freedom that it brings.
Our goal is to turn the Agile community itself into the informal “certifying” authority. Your peers around you will see the results you deliver. They will look for ways they can help you become better and how you can help them.
Join us in September, and we’ll build this together.
Last week, 22 Assembla team members came together from 10 countries to solve current problems and make plans for the next year. We met in beautiful Antalya, Turkey, over the Mediterranean, which the Turkish call the "white sea." We gained new energy and new momentum.
Assembla.com VP Sergey Golub wrote:
I would like to thank all of you for productive technical discussions and business ideas, for presentations you've made, for brainstorming big and small problems, for playing football/ping-pong/backgammon/chess together, for jumping in the waves in the sea and for lazy laying around a pool together, for singing in the bus during our travel and long walks in old city, for dancing turkish dances, for special English lessons and a lot of fun.
Sergey himself scored four football/soccer goals with a rocket right leg and grabbed a guitar from a local tavern performer to serenade us on Wednesday evening.
We worked at least 8 hours each day, from 8:30 to 12:30, then broke out for beach/gym/lunch from 12:30 to 14:30, then met again from 14:30 to 18:30.
A few of the concrete results were:
- We feel the need for speed, delivered by database upgrades and sharding.
- We will continue to break Assembla into smaller services and implement the MAXOS pattern. This is a megatrend that all of our development and ops guys are excited about.
- We will help you manage more of your Fast IT projects faster with a top level Portfolio Cardwall showing projects as them move through various stages, with summary reports. The wireframes and customers interviews for this are already well advanced.
- While we were there, we implemented the top request from our GitHub tool users allowing you to add multiple GitHub repositories in an Assembla project. This makes it easier to use Assembla's ticket and project management tightly integrated with GitHub repositories.
- We finished wireframes to reorganize the repositories under one tab, where you can easily access and add Git forks, Subversion, P4, GitHub or Bitbucket integration, deploy tools, and more - all of your coding needs in one place.
- We created a status page so users can easily view of the heath of our services with the ability to subscribe to real time communication.
- We will be trying out some experimental services to help you "get it done now." That's all I can say about it.
Thanks to the team, it was a lot of fun. Check out some pictures from our trip below:
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Any UX designer wants to create a software tool or an app that would appeal to users. Designers employ various techniques and practices to emulate users’ behavior or to define user behavior flows, and it’s a common belief that these techniques are all they need to design a successful product. However, there’s one cornerstone to all the things UX that often remains neglected, as I was able to observe. It’s hardly that the techniques alone would take UX designers to where they want without this essential base. I’ll try to shed some light on what that is.
It seems that UX design practices can be roughly broken down into the following:
- Designer toys
- User mirrors
- A mix of both the above
Let me explain. What I call “designer toys” are the techniques that designers commonly use to better define their own vision of how users will behave inside an interface. What I call “user mirrors” are the techniques used to gather evidence, factual or intuitive, of how users want to behave in the context of a user interface. These mirroring techniques include all kinds of A/B testing, surveys, etc., and it is assumed that designers exercise empathy with users.
With the mix of designer toys and user mirror techniques, the outcomes of A/B testing and feedback from users are taken into account for new design versions. Having received certain signals from users, designers then use wireframing, personas, storyboarding, Design Studio methodology, a pinboard for design ideas, sketching, paper prototypes, etc. This mixed approach will be mostly required to improve an existing product or an app.
However, those many techniques fall short in the face of one ultimate deal breaker (or deal closer). Interaction design, or user interface design for that matter, is supposed to facilitate interaction between a user and an interface in a context shared both by a user and a software product. A friend of mine puts it that way:
The hows will appear if the what becomes clear
No sketching or wireframing technique will ever help communicate the strengths of a product or an app. If users act in the context that differs from what is implied by designers, or by the whole product dev team, it’s likely that subtle UI perks and niceties will hit the barren ground. A very drastic example: can you imagine a pre-historic human using an iPad? It took millions of years to bring this living being to the context in which an iPad gives a clear “what”.
On a softer level, Facebook was able to hitchhike along with users because everyone wanted to stay connected to their friends online. It’s a whole other story that now, after about 10 years, we’re witnessing the opposite trend, and Facebook is in decline.
So, the ultimate thing that makes for a success of a product would not be a user interaction design, or UX design. This whole user+product=love thing can only happen if users and product makers share one vision. It’s very *cool* when one only needs to analyze the needs of users who act within one established paradigm of thinking. Things get a lot more exciting when the vision that a product team brings into the world is innovative, and users are not yet fully aware of what this product can do for them. In this case, playing with designer toys will resemble shooting at a target randomly in sheer effort to hit the bull-eye. It won’t work. User vision design comes first, UX design goes next. UX design is more of a technician activity, because once a shared vision of something exists, people usually do not make any big difference with their designs, they mostly borrow tricks from each other and follow each other’s steps.
Designing user vision is a whole other story. It involves having a clear product vision in place with the insiders (product dev team/executive/designers), and their ability to communicate this vision to the outsiders. Insiders need to come up with compelling proofs of how their product helps people do things better/easier, from a totally new perspective. Social sharing apps capitalize on the designed user vision that social sharing is hippish. Another case of user vision design is promoting Big Data as a panacea for organizational problems. Agile software development methodology has produced a vision for users as well. I can go on with more examples, but you get the idea.
UX designers need to keep in mind that successful design goes far beyond graphical or interaction design. For innovative products, it also includes user vision design.
Axosoft’s API is a powerful tool that allows developers to build custom applications and extend the functionality of Axosoft Suite. Because of this, we decided to build a .NET API wrapper. This wrapper isolates developers from having to worry about spending too much time learning the details of a RESTful API or the nitty-gritty details of Axosoft’s API.
I know what you are thinking: this is all good, but how do I use it? Well, lets get straight to it.
To simplify things, we made the AxosoftAPI.NET library available as a NuGet package (available here). The first step is to add the AxosoftAPI.NET NuGet package to your Visual Studio solution. Depending on your preferences, you can install the package through the ‘Package Manager Console’ or the ‘Manage NuGet Packages’ window (how to install a NuGet package). In either case, the ‘AxosoftAPI.NET’ library reference will be added to your solution. You are now ready to start using the API wrapper.
Note: optionally you can download the source code and add it to your solution. Whatever you think is best for your project.
Now it is time to start typing some lines of code.
We begin with some ‘using’ statements (these are optional as you know, just keep in mind that these code examples will not use the classes’ fully-qualified names):
Then we need to create an instance of the AxosoftAPI.Net proxy. Here is how:
Basically you need three values: a URL for the account being used; and a set of client id and client secret keys either from the account being used (see here) or in the case of 3rd-party applications one provided by Axosoft (see here).
Next, we need to authenticate against Axosoft. Our API uses OAuth2 protocol for authentication and authorization. In this example we show how you can easily authenticate using the Username/Password option:
Note: The AxosoftAPI.NET library also exposes a method for authenticating using the ‘Authorization Code’ option, but it is up to the developer to handle the necessary redirects required by the OAuth2 protocol (example application).
Before we start making calls to Axosoft’s API, it is important to point out a couple of things. The first point is that all calls made are dependent upon the permissions of the credentials used to authenticate. For example, if you have five projects in Axosoft, but the credentials used only have access to three projects, then when making a call to get all projects the API will return only those three projects. Makes sense, right?
The second point is that all the results returned by the library are wrapped on a class of type ‘Result’. This class contains three properties as shown below:
The ‘Data’ property contains the corresponding result return from the API; the ‘ErrorMessage’ contains the error returned by the API or ‘null’ if there was no error; and lastly, the ‘IsSuccessful’ flag is set to ‘true’ if no error, or ‘false’ otherwise. Pretty straight forward.
Ok, so let’s start making those calls I promised. The following example shows how to get all projects:
Wow, that was easy.
Here is a piece of code from a console application which gets all the projects and then loops through them and writes to the console the projects Ids and names:
In this case we used the property ‘Projects’ and its method ‘Get’ to retrieve the project. The AxosoftAPI.NET proxy has a property for every resource listed in our API documentation. Each of these properties is an interface for one or more methods. These methods map one-to-one with the different HTTP request allowed by each resource. For example, let us look at the ‘Contacts’ resource. From our documentation we can see that it allows for six different calls:
If we now look at the ‘Contacts’ property in the proxy object, we can see that it contains a method call for each one of these HTTP requests:
Note: the ‘Update’ method corresponds to the POST-update HTTP request; and the ‘Create’ method corresponds to the POST-create/add HTTP request.
Keep in mind some of these methods have overload methods as well. For example, the ‘Get’ method has a one-optional-parameter method which will return all objects; it also has an ‘integer’ – resource Id – parameter method which will return one single object based on the Id value.
Here are a couple of examples from the same console application for creating a new project and adding a new feature to it:
Described in a few words, you need to create a ‘Project’ object, populate the Name property – all other properties are optional – and pass it as the single parameter to the ‘Create’ method of the proxy’s ‘Projects’ property.
Then, for the new feature, you need to create a new ‘Item’ object, populate the corresponding properties (see our API documentation for more details about required fields and other notes), and then call the ‘Create’ method of the proxy’s Feature property.
Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. Adopting an agile process does not let you magically have a more successful product. What makes agile powerful is also makes it dangerous.Triage and Urgency
One tenet of agile is to make decisions at the last responsible moment.
Following this powerful and easy-to-remember mantra reduces the risk that you are wasting time on unnecessary work. This approach also maximizes the opportunities to better inform your decisions and actions. By delaying when you do any particular activity, one of two outcomes is created. Either the activity is never done, or the urgency of the activity grows until the penalty for delaying is larger than the risk of wasted effort.
There is always more work to be done, than can be done. Product managers and product owners know there is always more work to be done. Either implicitly, or explicitly, a product roadmap is a plan built on a series of hypotheses. There is always an opportunity to validate or refine every one of those hypotheses. The art of good product management includes having good instincts about which hypotheses embody too much risk, and which ones are solid (enough).
Every day’s work, when you’re being agile about it, should start with the question – “what is the most important thing for me to work on, today?” There’s a problem, not with the concept, but with the application. Most people conflate urgency with importance. There’s even a matrix to help people deal with this. Combine this with the “last responsible moment” mantra, and urgency becomes the trigger in their triage process.
The weakness of an urgency-driven triage-based approach is that it only looks at one side of the coin. Triage helps you avoid wasting time on unneeded activities. It does not prevent you from skipping needed activities. That’s the other side of the coin – important stuff which gets ignored because it never develops enough urgency until it is “too late.”
Ever heard of a team who deferred creation of an automated test harness because everyone is too busy fixing bugs? What about a team which has too much on their plate to consider refactoring? Too busy grooming the backlog for the next sprint to invest in developing a strategy?
This happens because our intuition about urgency is not good enough to balance the immediate with the long-range. Evolution wired us to respond to hungry predators – urgent problems. It seems reasonable to me to expect us to be weak at estimating the “actual urgency” of activities with limited immediate benefits and very immediate costs. The expression dig your well before you’re thirsty keeps coming to mind for me.Game Theory
So, it turns out you can play a variant of the prisoner’s dilemma with your future self, by looking at the benefits and costs of your actions, both today and in the future. You do this by imaging the cost-benefit to your present self versus your future self.
Paul Young’s recent (and good) article about the conflict between agility and strategy is what inspired me to explore the following scenario.
Consider the bi-weekly choice you have to make as a product manager / owner: Do I fill up the backlog (Scrum process) with the best stories I can today, keeping the development team busy; or do I spend two weeks improving my strategy by getting and processing information about the market?
[Note: I know I'm creating a false dilemma to amp up the drama. Pretend I'm being reasonable and talking about changing the proportion of time being spent on each activity]
If I fill up the queue of work for the team – to the best of my present ability, based on what I know right now - I incur a small immediate cost – increased angst and worry about the quality of my strategy – and I receive a large immediate benefit – a content development team. My future self risks a large future cost – the strategy was wrong – and a small future benefit – the development team has been busy the whole time.
If I make the other choice – to invest in understanding my market, here’s what happens. My present self receives a small immediate benefit – satisfaction in an improved or validated strategy – and incurs a large immediate cost – my boss complaining about an idle development team. My future self will receive the large future benefit of a successful product and an ultimately successful and happy development team, if he doesn’t get fired first.
The immediacy and visibility of “wasting” the team is obvious*. In the grand scheme of things, it is also a very small cost. The uncertainty and abstractness of having the wrong strategy is vague and nuanced.
*I don’t really accept the premise that not building product is _always_ waste. If you’ve got a tree to chop up for firewood, how much time do you spend chopping, and how much time do you spend sharpening your ax? If I need to understand my market better, I can ask the team to sharpen their axes. Their time won’t be “wasted.”
Rich Mironov offered a great tip to me too – have the team pick what they work on for the current sprint. If you’ve shared your insights with them, they are likely to make on balance good choices, so the “waste” of any bad choices is further reduced. Thanks, Rich!
There’s a pretty good analog in how we approach diet and exercise. The small (but visceral) sacrifices we make in the present determine the large (but presently intangible) results we realize in the long run.
In reality, this is not an either-or decision, but a time-allocation decision. What percentage of your time do you spend on understanding your market? Or how much time do you “steal” from the tactical urgent stuff, to work on the strategic important stuff?
Because we under-appreciate the value of improving the strategy, and over-index the cost of immediate issues, product people (owners, managers, champions, presidents) will be biased towards addressing the urgent. Behavioral economists have a term for this – hyperbolic discounting .
This is what makes any process which amplifies or leverages urgency a bit dangerous. It biases us towards further under-emphasizing the not-visibly-urgent, yet still important.
Agile can be fantastic for your company. Agile is not, however, magic – if you do it wrong, and under-invest in strategic thinking, you could actually be worse off than if you had stayed in the waterfall.
There’s this thing…as Jim (James Shore) and I (Diana) have mentioned before, in the early days of Agile we would visit teams and hear, “This is the best job I’ve ever had. I love this work.”
People who were doing Agile (usually Extreme Programming) were excited about it, they shared it with others, who did it, and got excited.
But at some point, someone shared it with someone who got excited about it and shared it but didn’t DO it, so their sharing lost a bit of fidelity, like a copy of a copy. Hearing about a thing is not the same as doing a thing.
Both the virtuous cycle (doers sharing with doers) and the vicious cycle (talking about-ers sharing with talking about-ers) continue, but now more than ever in the internet age, talk spreads faster than action.
We’re drowning in ideas, opinions, gossip (“Tell me how you failed at Agile”) and complaints about Agile, and have less opportunity to experience the real deal. At many conferences (and now through an Agile Alliance program), Experience Reports are a sought after item. People still want to hear from the successful doers.
And yet, the doing is so small in comparison to the talk, that the effective practice of Agile is in danger of being overwhelmed by the talk.
In other words, Agile is becoming a way of achieving only, “Well, my job doesn’t suck as much as it used to.”
In yet other words, Agile is in danger of being redefined as poorly done Agile.
So what to do? To achieve Agile done well and the best jobs ever, we need to feed the virtuous cycle and starve the vicious cycle. We need doers working with doers. We need the Agile Fluency Project.
We need you. Sign up. Beg, borrow or steal the time and money and join us in September.
We are happy to announce that you can now add multiple GitHub repositories within any Assembla project. Note: The same update was also applied to our Bitbucket tool/integration which works similarly to the GitHub tool discussed below.
If you are not familiar with the GitHub tool, it allows you to integrate GitHub repositories with Assembla’s tickets and activity stream. Previously, projects were limited to one GitHub repository per project, but a recent survey concluded that the biggest improvement we could make to the integration was to allow multiple GitHub repos per project. We listened.
While Assembla is well known as the best Subversion host, as well as a rock solid Git host, we understand that our users may prefer to use GitHub (or Bitbucket) for various reasons. Existing users already using the GitHub tool expressed their love for being able to use GitHub seamlessly with Assembla’s ticket, collaboration, and project management tools. Instead of fighting this, we want to embrace it with a seamless integration that we will continue to improve.
“Assembla's GitHub integration allows our team to enjoy the best of both worlds - GitHub's developer community and team development features tightly integrated with Assembla's task planning and tracking, wikis, and other project management tools. We can easily reference and update Assembla tickets with GitHub commits and see all project activity in one unified stream via Assembla. The combination of tools works great for our team."
Michael Katz, Principal Software Developer, Kinvey
To add a GitHub repository to your Assembla project, visit the Admin section > Tools page > and click ‘Add” next to the GitHub tool. Once one has been added, the button will now say ‘Add Another’ to add multiple GitHub repositories. Once the tool has been added, you can click on it in your navigation > enter your repository URL > and follow the on page instructions to finish setup.
Thank you everyone who participated in the survey that lead to this improvement. If you have any other feedback regarding this integration, or improvements to any other tools, please visit our feedback site.
If you do not have an Assembla project and would like to check out this integration, try Assembla out for free.
After the successful launch of the Agile Africa Conference in 2013, it will be taking place again this year on the 11-12 Aug 2014 in Braamfontein, Johannesburg. The “Agile Africa” Conference aims to showcase Agile software development within an African context. Follow this link to find out more and to register online. Applying Kanban (Foundation) […]
The post News update 2014/06 – Kanban & Leadership Training appeared first on ScrumSense.com.
I usually come across two classes of workitems in agile projects as I train, consult and coach clients at VersionOne.
- Class A workitems: Customer-driven or user-driven stories, features, epics, business initiatives
- Class B workitems: By definition, everything else. Several examples are listed below:
- Defects fixing work: Defects pushed out from earlier sprints, or reported by users in their production environment while the current sprint work is going on.
- Porting work: For example, port software from IP v4.0 to v6.0, port software from the existing database system to a different database system, port software to support multiple browsers, etc.
- Spikes: Proofs of concept, prototypes and experiments to reduce the technical risk and gain knowledge
- Develop test suites: Develop automated or manual test suites for various non-functional system-wide requirements, such as performance tests, usability tests, security tests, inter-operability tests, scalability tests, availability tests, system tests, etc.
- Run test sets: Run test suites (automated or manual) for various non-functional system-wide requirements listed above; run manual or automated regression tests sets; log defects found along with steps to reproduce the defects.
- Architecture runway work: Technical infrastructure design and coding effort necessary to support upcoming features in the nearer-term without excessive, delay-causing redesign. This type of work is becoming increasingly important as agile projects scale up. For further details, see the SAFe web site.
- Infrastructure work: Set up or improve development, test, build environments; continuous integration server; continuous delivery (DevOps) systems, etc.
- Dependency management work
- Online help, tutorials, release notes
- Technical debt reduction work
- Customer support team training
- General Availability (GA) release packaging
Often Class B work may represent as much as 30% of the total work if it is fully accounted for and properly estimated. For so-called hardening or stabilization sprints, all work is Class B work. However, Class B workitems are often not properly inventoried and logged in the agile application lifecycle management (agile ALM) tool; they are poorly estimated and poorly planned. Consequently, they come back and haunt the team during sprints as unplanned or underestimated work – sort of their revenge for not receiving the respect they deserve. These two classes of workitems are compared and contrasted in Table 1.
Treat all workitems as pretty swans deserving your full attention
No workitem should be treated as an ugly duckling. Here are several concrete steps I would like to recommend so you can treat all workitems as pretty swans:
Ownership: If the product owner is reluctant to own or support Class B workitems, or does not have a good understanding of them, team members should have an honest discussion with the product owner about the reasons, cost and benefits of Class B workitems. The discussion has to be along the lines that if we don’t take proper care of Class B workitems, the team will continue to increase its technical debt and end up lowering productivity in the future. In fact some Class B work (such as defect fixing and running test suites) even has impact on users. On the other hand, if we spend reasonable effort on Class B workitems (10% to 20% in our view), it will lay the foundation for productivity growth in the future. If necessary, senior management (perhaps facilitated by the ScrumMaster) may need to play a constructive role here, as there is never-ending pressure to deliver more and more Class A stories demanded (or thought to be needed) by customers and users.
Inventory and Visibility: There must be a full and proper inventory of all Class B workitems. They need to be logged into the agile ALM database with clear and complete description along with appropriate acceptance criteria.
Analysis: The analysis methods for Class A vs. Class B workitems are different. The product owner or business analyst explains and clarify Class A workitems. Team leads (development leads, QA testing leads) and other subject matter experts clarify various Class B workitems. Analysis of both Class A and Class B workitems should be done preferably one time-box ahead of their design and development time-box, as explained in my sprint pipeline blog post. Only with proper analysis effort can one clearly understand what needs to be done for each Class B workitem — the prerequisite for estimating, planning and the actual implementation effort.
INVESTment: Class B workitems also need proper INVESTment. They need to be independent of each other (at least the specification level). They should be negotiable between the product owner and the team, with both sides coming to an agreement on the scope of the work and what is outside of the scope. Although the value for some of the Class B workitems (such as spikes, architecture runway and technical debt reduction) is not immediately relevant to customers or users, the product owner needs to understand this work is important to reduce the technical risk and to improve the productivity (velocity) of future sprints. The team members should be able to break down large Class B workitems into smaller Class B workitems that can be completed in a single sprint. Each workitem needs to be testable.
Acceptance criteria and acceptance tests: Class B workitems must have acceptance criteria as agreed upon between their owners and the team, with concurrence from the product owner. Depending on the nature of the workitem, acceptance tests may be a matter of going through a checklist (for completion of release packaging or training the customer support team). Or it may be running and passing test sets, fixing, verifying and closing defects, checking that the spikes have produced the desired technical information (or if you’ve run out of the allocated time for the spike), online help is reviewed to match with working software, etc.
Estimation of effort: This creates challenges for Class B workitems. The practice of estimating Class A stories in story points using Planning Poker or the Table-top estimation method is quite common. But what about estimating all Class B workitems? Relative size estimation is a powerful technique, but it needs to be applied to stories of the same or comparable type so you can do a sensible apple-to-apple comparison in estimating relative sizes. If you compare relative sizes of disparate types of workitems — such as comparing stories with defects, stories with porting work, spikes with technical debt reduction, or test automation with training/online help — the comparison and resulting story point estimates will not be very meaningful. This is one of the reasons why some teams don’t bother to estimate Class B workitems, which is a mistake, as explained above.
I suggest that a team simply estimate the work effort for each Class B workitem in ideal hours, either based on the team consensus or based on estimation by experts in the team who are likely to do that specific workitem, such as a spike, porting work or online help. Many Class B workitems do need specialized expertise and it makes sense for the team member(s) to do that work to estimate it. This is a more appropriate way to estimate the effort than using relative size estimation to compare non-comparable workitems (it would be analogous to comparing apples to oranges or comparing apples to other objects like tires or stones).
Once a Class B workitem is estimated in ideal hours, it is very easy to convert that estimate into normalized story points by dividing the estimate in ideal hours by the Normalization Basis chosen by the enterprise, as explained in Part 4 of my blog series on the topic of Scalable estimation and Normalization of story points.
Normalized story point (NSP) = Estimate in ideal hours / Normalization Basis
For example, if the Normalization Basis is chosen to be 20 hours for an enterprise, then a defect estimated to take 4 hours to fix, verify and close is equivalent to 4/20 = 0.2 NSP. A spike estimated or budged to take 30 hours is equivalent to 30/20 = 1.5 NSP. And a porting effort estimated to take 120 ideal hours is equivalent to 120/20 = 6 NSP.
All Class A story points are also converted into NSPs as described in detail in my blog series on the topic of Scalable Estimation and Normalization of Story Points.
Now all Class A and Class B stories will have the same scale for expressing their estimates, i.e., normalized story points. This will make all story point math, reports, and metric meaningful and accurate.
Planning: Sprint planning must take into account both Class A and B workitems. After analysis and estimation steps, planning involves making sure that the planned work is consistent with historical velocity or available capacity. Let’s say the team has exhibited a stable average velocity of 25 (normalized) story points over the last 3 to 4 sprints comprising of both Class A and B workitems. Then under the so-called “Yesterday’s Weather Model” (same team members, same technology platform, same application domain, etc.), the team should plan on undertaking about 25 normalized story points worth of work (comprising of both Class A and B workitems) in the upcoming sprint being planned. If the Yesterday’s Weather Model is not applicable, the team will need to do capacity-based planning considering how the team capacity will be used to perform both Class A and B workitems. The product owner should rank-order the entire sprint backlog of both Class A and B workitems using the ranking method of his or her choice.
Status of Workitems: As all workitems of Class A and B are treated on the equal footing as explained above, all workitems are pretty swans. There should be no ugly ducklings. Planning, execution and retrospectives will all benefit from this approach. And the teams, projects and organization can only benefit.
Do you have any ugly ducklings in your agile project backlog? Can you think of any ugly ducklings that are not included in the Class B workitems list? Remember that ugly ducklings often have a disruptive effect on the well-planned work for pretty swans. Ugly ducklings can turn pretty swans into ugly ducklings, too.
Do resolve to treat all your workitems (both Class A and B) as pretty swans. From your team’s successive sprint retrospectives, your team should be able to judge whether the problems caused by ugly ducklings are going down steadily, sprint by sprint; if not, what corrective actions must the team take? Many corrective actions are presented in this blog (see the concrete steps presented above). In short, avoid the pretty swans vs. ugly ducklings dichotomy.
A better approach, when facing such uncertainty, is to create a rough initial plan, with some detailed first steps, and revisit the plan as more is known and the next steps are needed.
The team working on a Parkour mechanic is implementing some IK motion and wants to blend it with animations. They're not sure what will look good or what type of animation or blending will be needed, or even if they'll have time to iterate on animations once the IK is in place. Rather than try to plan all the work out on the first day of the sprint, they'll spend an hour and identify the initial tasks to try IK in place. Near the end of the week, they'll spend another hour discussing their progress and identifying the next steps to take, including what animations they'll want to try blending in.
Note: there will likely be other stories for the animators to work on or they will be shared with another team.
By spending a quarter of the time, the team will have more time to spend on the feature and actually identify the work more accurately: it will respond better to the emerging mechanic and iterate more effective, rather than relying on the initial plan being correct, which was based on a good amount of assumptions.
So why don't more teams do this?
- Trust: Management often wants to see a detailed plan coupled with a firm commitment to achieve that plan. They don't yet trust the team to "wing it" with uncertain features.
- Certainty is preferred over maximizing player value: Many organizations are task focused: a developer's success is measured by how well they meet their scheduled assignments. Using an emergent sprint backlog requires a "value added over task estimate" approach acknowledging that work emerges to achieve a value focused goal. This requires the ability for the team to safely say "we don't know".
- Responding to emergence
- Being accountable to value and quality
- Communicating with courage, rather than hiding behind a task list out of fear.