Here at Axosoft, we love our tech community, and we recognize the significant yet still underrepresented achievements and initiatives of women in the technology industry in AZ and abroad. As a tech company with a female CEO, we are not only active in supporting the tech community and championing the women at its forefront – we are actively seeking to expand our female workforce by adding more female developers to our team.
What better way to find female developers than to help create them? Don’t worry, we don’t mean in a creepy futuristic cloning way. Axosoft has partnered with CodaKid, a Scottsdale-based kids computer programming and game design academy, to offer fun and free workshops and codeathons that teach girls how to code as early as age 6.
We are constantly trying to align ourselves with great partners like Girls in Tech and CodaKid who share our vision for growing STEM education and the tech industry. As prominent players in the Valley’s technology ecosystem for over a decade, we are honored to be the lead sponsor of the Girls in Tech Catalyst Conference!
The speakers at this event represent some of the very best technological innovators, thinkers, entrepreneurs, and leaders in the Valley. And, it just so happens they are women. These superheroes, alongside the attendees of the conference, showcase just how strong, energetic and productive a network of driven and influential women exists in Arizona. This conference shows off the amazing women doing things right now on our own turf, and in doing so represents similar innovations globally.
We are SUPER excited to partner with Girls in Tech in celebrating the vibrancy and diversity of this growing movement, sharing in their vision to empower women in the technology industry, spread knowledge and inspire more companies like ours to create the next big thing.
So, how are the people challenges of DevOps more important than the technical challenges?
Recently I was reading Puppet Labs’ State of DevOps Report. Similar to VersionOne’s 9th annual State of Agile™ survey, this report has an interesting set of conclusions about the current state of DevOps. One of the things that I’ve been considering for some time is the strange proximity of DevOps people to technical problems.
There are a lot of technical aspects to doing DevOps. One example is continuous integration. When releasing, everything needs to be integrated and checked, no matter how small. DevOps takes it one step further with continuous deployment since you need to set up acceptance tests and unit tests, and all tests have to be automated.
One of the aspects of DevOps that reading this survey reinforced for me is that the folks who do DevOps the most successfully focus on the people aspect as much as, or sometimes even more than, the technical aspect. This brings the Gerry Weinberg conundrum to mind. Gerry Weinberg, considered by some to be the grandfather of agile, said that there’s always a people problem. The technical focus of DevOps may lead you to think that there isn’t a people aspect to focus on. In reality, while the technical piece is a focus, the people problem is huge and even more important.
DevOps is about bringing the functions of operations and development together, which means you have to break some stereotypes. You have to think outside the box. Those on the DevOps team must have the will to think about each one of the development stories through the post-deployment lens. Do you have monitoring as part of what you’re doing? Do you have performance constantly tested? Do you have all aspects of your tests automated? If not, then you’re probably not going to be as successful with DevOps.
This sounds technical, but it’s actually more of a people problem. It’s employing DevOps engineers who remember to do that. It’s not asking the question of should you automate, but how will you automate this specific story? That’s huge and it’s vital. It needs to be addressed and it needs to be addressed successfully. If you don’t, then you’re not tall enough to ride the ride. It’s not worth your time and energy to claim to be DevOps if you can’t do those things. DevOps takes time, energy and nurturing. It takes the willingness for individuals to step up. And it takes the willingness for management to step back and give your people the opportunity.
There were a couple of other fascinating people issues that that survey brought to light. The number one key to success in an IT organization, according to this survey, was employee happiness. This is an aspect people need to listen to this and build on. Employee happiness is number one. It proves that even geeky programmers like me don’t derive our employee happiness only from the really cool tools we get to use and work on. It’s nice, but it’s not enough.
The other fascinating people issue was getting the whole team together to work on the issues, thus becoming a cross-functional team. Everybody is responsible for everything, and that makes a huge difference in the DevOps world, even more so than in the traditionally agile world. Teamwork is where you’re really going to see the difference between just checking things in all the time and continuous deployment.
DevOps lends itself to being viewed through a technical lens, but the people aspect is what differentiates you from success or failure. I hope I have inspired you to take a closer look at how you are balancing the people aspect of DevOps with the technical.
So, what are some other people aspects of DevOps that should be focused on?
Need assistance with a Continuous Delivery/DevOps Assessment? Click here for info.
VersionOne and State of Agile are registered trademarks of VersionOne Inc.
In a Certified Scrum Product Owner class I was teaching recently we got to the part about how it was up to the teams to figure out the best way to solve the business problems presented in the User Stories. We discussed the logic behind this and everyone seemed to be in agreement that it made sense that the people who do the design/coding/testing on a daily basis were the ones most familiar with the technology, the environment and the context of the needs of the end user and that it made sense for them to find the best way to meet the needs of the end user.
It was all going just fine until one of the participants in the class asked a very simple question…
“How do I know they are going to do it the right way?”
The question came from someone who was moving out of the role of lead developer into a Product Owner role.
The short answer, “You don’t. You have to trust them.”
He winced. And this is where things got twitchy. The person asking the question understood that he was supposed to trust. The problem was that understanding this intellectually, and actually doing it were two completely different things.
“Yeah, I know… but really… how do I know they’ll do it the right way?”
We talked about shaping the scope with the Acceptance Criteria, and talking with the team about any known challenges they were going to face, but that at the end of the day, it was the people doing the work that were going to have to be given the freedom to find the best way to solve the challenge placed before them. The “… but really…” question was raised a few more times and it seemed like there was a fading, desperate hope that there was going to be some secret magic answer or trick that would resolve the fear that “they” might make a mistake. Unfortunately, there is no magic answer to this. The simple fact is, “they” might solve the problem in a way that met all the needs of the User Story and it’s Acceptance Criteria but it might not be in line with how the PO would have solved the problem on his own. There is the chance that the solution the PO had in mind might have been a better way, but there is also a possibility that a team of talented, skilled individuals, working together might come up with a solution that was as good, or possibly better, than what the PO was envisioning.
If the Team delivered a solution that met the needs of the story but was somehow still not what was needed, this would become apparent during the Sprint Review meeting when the work was shown to the Stakeholders. One of the benefits of working in short iterations is that we can find problems and learn from them quickly, getting better every step of the way – both in delivering value and in working together. The longer the PO and the Team worked together, the better they get at defining and working on the User Stories.
For this particular PO, and for many people who are moving towards Agile, being open to the possibility that others may have solutions which are as good as, or better than we have isn’t an easy pill to swallow. One of the dysfunctions inherent in a traditional approach is that a command and control way of working was put in place because of the the assumption that if we don’t tell people how to do something, they’ll do it wrong.
But what if they won’t? What if they’re as smart, or smarter than us? Are we willing to let go and accept the risk of trusting again? It’s easy to say yes, but actually doing it – that is much harder. It is also one of the most challenging parts of making the switch to Agile.
Regardless of whether you are a member of the Team doing the work, someone playing the role of Product Owner or ScrumMaster, recognizing the places where the fear of trusting creeps in, observing your reaction and finding a way to take the chance of trusting people again is always hard. And it isn’t just about trusting others. We also have to learn to trust ourselves to make good choices and allow for the possibility of making mistakes and learning from them. How else are we going to get better?
Regarding the light bulb, Thomas Edison is often quoted as having said:
“I have not failed. I just found 10,000 ways that won’t work.”
If Edison had not been given the chance to find the best way to create his version of the light bulb our world would be very different than it is today.
The Scrum Guide says “Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.” This may well be true, but for Agile to sink in and really take root, those three pillars have to stand on a solid foundation of trust. What we trust in is not that people will always be “right”, but that we will run these experiments and learn every step of the way.
And who knows, there is always the chance that the Team may surprise you by coming up with a solution that is even better than the one you had in mind.
Brainstorming a list of topics for a Scrum/Agile lunch-N-learn session.
Slicing Stories – resources to slice vertical stories of valueStory Writing techniques: w/ Q&A based upon participants real storiesEstimation techniques: Affinity Estimation; T-shirt sizing -> converting to numbers; Planning Poker (the rule book)Team building tools: Infinite Loops; Helium Stick; Warp Speed; Pair Drawing, etc.Definition of Done/Ready exerciseRelease Planning How to derive duration with a complicated backlogAgile Library Initiation Bring books, make the rules, get funding, 1,2,3, GO!Management 3.0 Book Club - join a group reading the best Agile book written.Making Visual Information Radiators - define Radiator/Cooler; elements of a Scrum boardAspects of an effective Product BacklogAgile Portfolio Planning - tools and techniques; estimation, cost of delay, prioritization, deciding what NOT to doThe principle of TDD via LEGO building; anyone can learn the power of test first developmentDoes you development rest on a SOLID foundation - an overview of the SOLID principlesCollaboration Games to understand the customer; 12 Innovation Games; Other resourcesUser Story Maps technique to achieve higher level understanding of the backlogLaunching a Team; what’s required, best practices, examples and techniquesTeam Practices: a collection of quick tools to increase team work and collaborationLearn Backlog Prioritization techniques: Cost of Delay, Perceived ROI, Delivery Order, Gut Feeling, Loudest Yeller
Why? For the same reason. Clickbait, like multitasking, destroys productivity. At least for my own purposes, I have decided do something about it, and I am wondering if other people feel the same way.
What is clickbait? Let's say you an article open a reputable site, like CNN.com. See all those links on the right side, like Opinion, More Top Stories, Promoted Stories, More from CNN? That's click bait. My guess is 1/3rd of any given web pages consists of catchy headlines whose sole purpose is to get you to spend more time on their site (or maybe, to cash in on Cost-per-Click syndication schemes, to get you go to some other site). By the time you get 2/3rd down the page, 100% of the content is usually clickbait.
What is evil?What do I mean by evil? Evil things are bad for you. Like weeds in the garden or corrupt politicians, you'll never get rid of evil entirely, but if you don't keep the weeds under control, you won't have a garden any more. So we need to keep evil things in check, lest you suffer the consequences. In this case the consequences is massive amounts of wasted time (at least for me it is)!
Why is Multitasking Evil?I have long known that if you have two goals, working them in parallel slows you down. If goal A takes a month, and goal B takes a month, then if you work on A and B in parallel, it will take you at least 2 months before either goal is finished and probably longer. So focusing on one thing at a time usually gives you better results. This is why focus is a core value of Scrum.
It turns out the situation with multitasking is much worse than I thought.
I recently attended a talk by Prof Lutz Jäncke, the neuropsychologist at the ETH, on why teenagers are the way the are. (The short answer: they are not evil, they are drawn that way. They will be people again when their brains have finished developing -- sometime around 20 years old. But I digress.)
Listening to a neuropsychologist for an hour was very challenging! My brain was very tired after his talk, but one point really stuck out:Multitasking makes you worse at multitasking!To process information effectively, we need to filter irrelevant information. By responding to every stimulus that comes in, we lose the ability to filter junk.
He also asked, have you ever gone to do something on the Internet, lost track of what you are doing and then wasted a tremendous amount of time? You bet! Every day! Why is that? Clickbait. Catchy headlines and dramatic pictures pique my curiosity to send me to the next page.
I realized this was true, and I am now trying to turn down the interruptions on my computer and other devices.Using Adblock Plus to fight clickbaitI have used ABP for a long time to block most ads. But the standard filters only target ads, not clickbait. I discovered you can not only block links, but you can block specific HTML elements. After a bit of experimenting with the block element feature, I was able to filter the clickbait sections of the news and entertainment sites I visit most.
I was amazed at the difference in how much less clutter and fewer distractions I encountered!
Do you have this problem? Would you like to use my filter list? I don't know if it is worth packaging these filters for distribution. Or of there isn't a filter set somewhere that addresses this problem. So I have simply published this list and installation instructions on as a google doc: http://tinyurl.com/clickbait-filter. It's still pretty short, but if you send me additions, I will integrate them.
Clickbait is evil. I believe reducing clickbait will be good for my performance, and it probably will be for yours as well. If you install it, please put out a tweet like this:
"Just installed @peterstev's clickbait filter! #clickbaitisevil! http://tinyurl.com/clickbait-filter"
We can all agree that inspiring children to become engineers and scientists is of utter importance. However making a difference on a local level seems intimidating. But it doesn’t have to be so difficult.
Learn how you can help us inspire a million children to become engineers by providing just a few hours a month and a safe, collaborative meeting space.
A few years ago Robert Holler, the president and CEO of VersionOne, challenged VersionOne employees to come up with an idea that would help children in our local community learn about programming and technology. This seemed like an exciting, though daunting, community service project.
At VersionOne we feel it is an important responsibility to help the community. That doesn’t mean just the agile community, but also the local community. In fact, Gartner recently recognized our strong community presence in the Magic Quadrant for Application Development Lifecycle Management report.
Typically when we do local community projects they are hosted by charities that manage projects. This project, on the other hand, would be completely managed by VersionOne employees. At first, this seemed like it might take a lot more time and effort than any of us really had. Nonetheless, we were very excited to try to make it work.
There were a lot of ideas that would need varying degrees of resources, but after a little research we discovered the global CoderDojo movement. It was a movement started in Ireland in 2011 by an eighteen-year-old student and a serial entrepreneur. They developed a vision for creating a safe and collaborative environment in which experienced adult mentors help students who want to learn about technology and programming. Their model was fairly lean, making it easy to launch. Parents bring their kids and their own laptops, so we just needed space and mentors to get started.
Since VersionOne is an agile lifecycle management company, we were attracted to the lean nature of this program. Soon after, CoderDojo Ponce Springs was born!
How It Works
The way it works is that parents bring their kids, ages 7 through 17, with laptops in hand to a meeting place. (In our case, we also have a limited number of laptops that have been donated by VersionOne for kids who don’t have a laptop). Volunteers help the students learn a programming language or other creative tools.
There are tons of great free resources like TeachingKidsProgramming.com, Khan Academy, Codecademy, CODE.org, Scratch, Blockly Games, and more. This makes it less burdensome for new volunteers to help because they don’t need to spend hours and hours creating their own resources.
We should stress, however, that the bulk of the work is on the students themselves! Mentors are there to assist and inspire, but not to provide long, drawn-out lectures. Students rapidly get hands on with the technologies and help each other learn. It’s a theme that’s woven throughout the CoderDojo movement. One of its own mentors is Sugata Mitra, who has conducted some amazing experiments in child-driven learning. Check out his TED talks to see what he discovered about the innate curiosity and capacity for learning and teaching that children possess.
Want to Start Your Own CoderDojo?
We share code and resources in GitHub in this open source and forkable CoderDojoPonceSprings repository. Feel free to create a copy of it and start one in your own community! Our Dojos take place in downtown Atlanta and in Alpharetta, Georgia, but one of our volunteers cloned our content and started a brand new CoderDojo in Henry County, about 30 minutes south of Atlanta.
It has been exciting to see the program still going strong for more than two years. The majority of the students are returning students, a good indication of the value they are getting from the program. In fact, many of the students have been participating for the entire program, and are becoming quite advanced. These are the students who have encouraging parents and peers outside of the Dojo as well, because it takes more just attending a Dojo to become really advanced.
What a CoderDojo is best at is providing the safe, collaborative environment for students who are ready and willing to learn to meet other enthusiastic peers with whom they can collaborate and increase their knowledge. Research has shown that when someone is learning something new, they often learn best from peers who are just slightly ahead. A CoderDojo also provides students who want to help others an opportunity to start giving back immediately. In one particular case, we had a student serve as a mentor to much younger students. He is thirteen and participated in a special event with students from an Atlanta elementary school.
A Million Children
Making a difference in the world can seem like a daunting feat, but the greatest lesson that I think has come out of our CoderDojo project is that by simply providing some space and time, we can inspire the next generation to get excited about programming and technology.
We probably have 300 different children come to our program each year. Over the next five years we hope to inspire 1,500 children in our program. If each of the three chapters that launched after ours has the same results, together we will inspire 4,500 children. And if 223 companies are willing to join us, we all can inspire 1,000,000 children over the next five years.
Volunteers in our Dojo are currently collaborating on tools and content to make starting a new CoderDojo even easier, if you’re interested to learn more or start your own CoderDojo, email us at email@example.com.
So what do you have to say, will you help us inspire the next generation of software programmers?
A product backlog stores, organizes and manages all work items that you plan to work on in the future. While providing agile training, consulting and coaching engagements at VersionOne, our clients often ask how to logically structure, organize and manage their product backlog. Clients also want to know how to prioritize or rank work items.
Here is a simple and easy-to-remember phrase that captures the key characteristics of a well-managed product backlog: Product backlog is DEEP; INVEST wisely and DIVE carefully … otherwise, by implication, you may sink (just kidding, but only slightly).
The key characteristics of a well-organized and managed product backlog are summarized in the image below. DEEP, INVEST and DIVE are meaningful words. They can be used as very useful acronyms to help us remember the key characteristics. In this blog, I will explain how to manage a DEEP product backlog well by INVESTing wisely and DIV[E]ing carefully.
Figure 1: Logical Structure and Key Characteristics of a
Well-Managed Product Backlog
The granularity or size of work items should be determined based on how far into the future you are planning a product, i.e., the planning horizon. The longer or shorter the planning horizon, the larger or smaller the work items. This makes sense as it takes a lot more effort to develop, specify and maintain a large number of small-grain work items compared to developing, specifying and maintaining a small number of large-grain work items. Smaller work items, stories, are typically developed by breaking down larger work items, epics. Stories are the unit of software design, development and value delivery.
DEEP product backlog
A product backlog may have several hundred or more work items, hence the acronym DEEP. Work items can be comprised of stories, defects and test sets. DEEP is also an interesting acronym capturing the essence of the logical structure of a product backlog.
- Detailed appropriately: Workitems in the backlog are specified at an appropriate level of detail as summarized in Figure 1 and explained below.
- Estimated appropriately: workitems in the product backlog are estimated appropriately as explained below.
- Emergent: Product backlog is not frozen or static; it evolves or emerges on an on-going basis in response to product feedback, and changes in competitive, market and business. New backlog items are added, existing items are groomed (revised, refined, elaborated) or deleted or re-prioritized.
- Prioritized as needed: Workitems in the backlog are linearly rank-ordered as needed, as explained below.
Sprint planning horizon, workitem granularity, estimation and rank order
If the planning horizon is the next, i.e., upcoming sprint or iteration (typically 2 to 4 weeks), each workitem is small enough to fit in a single sprint, and is 100% ready (“ready-ready”) to be worked on, as indicated in Figure 1 – see the top red-color region. A ready-ready story has already been analyzed with clear definition (User Role, Functionality, and Business Value) and associated Acceptance Criteria. Workitems planned for the next sprint are stories, defects and test sets. The workitems in the next sprint have the highest rank order compared to workitems in later sprints or later release cycles. I will soon explain how this rank ordering is done. The rank order information is used to decide the order in which the team will undertake work on workitems in a sprint backlog, and also decide which incomplete workitems to push out to the release or product backlog at the end of a sprint time-box.
Workitems in the next sprint collectively satisfy the well-known INVEST criteria; it is a meaningful English word, as well as an interesting acronym coined by Bill Wake (see his blog Invest in Stories and Smart Tasks). Its letters represent important characteristics of workitems in the next sprint backlog. I will now elaborate on the letters in INVEST acronym. Stories in the next sprint backlog should be:
- Independent of each other: At the specification level stories are independent; they offer distinctly different functionality and don’t overlap. Moreover, at the implementation level these stories should also be as independent of each other as possible. However, sometimes certain implementation-level dependencies may be unavoidable.
- Negotiable: Stories in the next sprint are always subject to negotiations and clarifications among product owner (business proxy) and the members of agile development team.
- Valuable: Each story for the next sprint offers clear value or benefit to either external users or customers (outside the development team), or to the team itself, or to a stakeholder. For most products and projects, most stories offer value to external users or customers.
- Estimable: From the specification of story itself, an agile team should be able to estimate the effort needed to implement the story; this estimate is in relative size terms (story points), and optionally, it can also be in time units (such as ideal staff-hours or staff-days for the whole team). Thus, stories are estimated in story points, and also often in ideal time units.
- Sized Appropriately: A simpler interpretation of this criterion is that each story is Small enough to be completed and delivered in a single sprint. The letter “S” can be taken to mean Sized Appropriately; specifically, each story should take no more than N/4 staff-weeks of team effort for an N-week long sprint (see “Scaling Lean and Agile Development” by Larman & Vodde, 2009, page 120.). Thus, for a 2-week sprint, each story should take no more than 2/4 staff-week = 0.5 staff-week = 20 staff-hours of effort. A story substantially larger than 20 staff-hours of total effort should be treated as an epic and be broken down into smaller stories. For a 4-week sprint, each story should take no more than 4/4 staff-week = 1 staff-week = 40 staff-hours of effort. If a sprint backlog has a mix of stories that are small, medium or large size stories (their average far exceeds N/4 staff-weeks), the average cycle time across all stories will increase dramatically reducing the team velocity.
- Testable: Each story specification is very clear to be able to develop all test cases from its acceptance criteria (which is part of the specification).
Stories may be broken down into implementation tasks, such as Analysis, Design, Code Development, Unit Testing, Test Case Development, On-line Help, etc. These tasks need to be SMART:
- S: Specific
- M: Measurable
- A: Achievable
- R: Relevant
- T: Time-boxed (typically small enough to complete in a single day)
If a story needs to take no more than N/4 staff-week of team effort (ex. 20 staff-hours for 2-week sprints), all SMART tasks in a story should add up to no more than N/4 staff-week of team effort. If you have 5 tasks, each task on an average should take 4 hours of ideal time effort or less. Stories and its SMART tasks for the next sprint are worth INVESTing in, as the return on that INVESTment is high because they are scheduled to be worked on and delivered as working software in the next sprint itself.
Release planning horizon, workitem granularity, estimation and rank order
If the planning horizon is an upcoming release cycle (typically 8 to 26 weeks, or 2 to 6 months long – consisting of several sprints), workitems are “medium-grain” as shown in the middle yellow color region of Figure 1. Typically, many of these workitems are epics; however, they should be still small enough to fit in a release cycle and can be completed over two or more sprints in a release cycle. These epics are typically called features or feature-epics. These feature-epics should still be specified with User Role, Action, Value and Acceptance Criteria formalism that is often used for specifying stories, but now you are capturing a larger functionality represented by a feature-epic. Feature-epics are divided into stories – small enough to fit in a sprint – before the sprint in which a story will be implemented.
Over the time horizon of an entire release cycle, INVESTing in stories for an entire release cycle has poor returns, because it takes a lot of effort to ensure that the INVEST criteria is being satisfied correctly for a large number of stories covering an entire release cycle, and those stories are much more likely to change over the release cycle spanning several sprints; so this kind of INVESTment may not yield expected results as stories will very likely change during an entire release cycle after they have been specified.
Feature-epics in a release cycle can and should be estimated in relative size terms, but without expending the effort needed to break down all feature-epics in a release cycle into individual stories. This epic-level estimation can be done by comparing relative sizes of epics. I have presented a detailed approach for doing so in Part 5 of my 5-part blog series on Scalable Agile Estimation: Normalization of Story Points. This method ensures that all epics and stories are estimated in a common currency of “normalized story point” which represents the same scale for an entire organization across all projects, sprints, release cycles, and teams. There is no need to estimate epics in “swags” or “bigness numbers” which are entirely unrelated to story points.
It still makes sense to rank order feature-epics in a release cycle to decide which ones will be scheduled in Sprint 1, 2, 3, and so on. However, this assignment may change as each sprint is completed and more information and learning emerge.
Product planning horizon, workitem granularity, estimation and rank order
If the product planning horizon is over multiple release cycles (typically 6 to 24 months) going beyond the current release cycle, workitems are “coarse-grain” as shown in the bottom gray color region of Figure 1. These large epics or super epics require two or more release cycles to complete. These super epics may be described in plain English (bulleted text) or with screen mock-up or video or prototype or with any form of expression suitable to express the intent and value of super epics. These super epics are divided into feature-epics – small enough to fit in a single release cycle – before the release cycle in which that feature-epic will be implemented.
Over the time horizon of multiple release cycles, INVESTing in stories has even poorer returns compared to INVESTing in stories for a single release cycle. This kind of INVESTment will not yield expected results as stories are very likely to change over much longer duration of multiple release cycles.
Large epics or super epics that need multiple release cycles to be implemented can and should be estimated in relative size terms, but without expending the effort needed to break down large epics into feature-epics, and breaking those, in turn, into stories. This estimation can be done by comparing relative sizes of large epics. I have presented a detailed approach for doing so in the same Part 5 of my 5-part blog series on Scalable Agile Estimation: Normalization of Story Points, as mentioned above.
It may not make much sense to rank order large epics over a multiple release cycle product planning horizon, as this assignment very likely will change over a larger time horizon; besides it does not matter if a large epic which is six to 24 months out in the future is rank-ordered 125th or 126th. That level of rank order precision is not required.
I use the strategy of INVESTing in stories and SMART tasks only for the next sprint backlog, but not doing so at the release or product backlog levels. INVEST just-in-time in the next sprint as you plan it. INVESTing in stories and tasks over a longer time horizon will yield poor returns.
DIVE the product backlog carefully
There is rarely enough time or resources to do everything. Therefore, agile teams must prioritize (rank-order, to be more precise) which stories to focus on and which lowest rank-order stories could be pushed out of scope when close to the end of a sprint. For agile development projects, you should linearly rank-order the backlog, rather than do coarse-grain prioritization where stories and epics are lumped into a small number of priority buckets, such as Low, Medium, High, Critical priorities. Linear rank ordering (i.e., 1, 2, 3, 4 ….n) avoids inflation of priority, keeps everyone honest, and forces decisions on what is really important. It discourages the “kid-in-a-candy-shop” behavior when the business side clamors that everything is of high-priority or of equal importance.
Note that epics and stories are conceptually different, and should not be mixed or aggregated while developing a rank order. An epic rank order is separate from a story rank order.
The responsibility of agile rank ordering is shared among all members of a team; however, the rank ordering effort is led by the product owner. Similar to DEEP, INVEST and SMART, DIVE is a meaningful English word, and also an acronym. Product backlog items should be linearly ordered based on the DIVE criteria, which requires careful consideration of all four factors captured in the DIVE acronym:
- Dependencies: Even after minimizing the dependencies among stories or epics (which is always a good thing to do), there may still be few unavoidable dependencies and they will have an impact on rank ordering. If workitem A depends on B, B needs to be rank-ordered higher than A.
- Insure against Risks: Business as well as technical risks
- Business Value
- Estimated Effort
In my blog post on Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method, I have presented a simple but fairly comprehensive method for linearly rank ordering a product backlog (both stories as well as epics). The blog explains how to model and quantify value, risk and effort for the purpose of rank ordering workitems in a backlog. I will not repeat those details here. The method is extensible, customizable and very practical. The Agile Prioritizer template makes the rank ordering effort easy.
Table 1 summarized how to manage DEEP product backlog with wise INVESTing and careful DIV(E)ing.
Table 1: Summary for managing a DEEP Product Backlogs with
wise INVESTing and careful DIV[E]Ing
I hope you find the statement “Product backlog is DEEP; INVEST wisely and DIVE carefully” a useful mnemonic to remember key characteristics of a well-managed product backlog. I would love to hear feedback from you on this blog here, or by email (Satish.Thatte@VersionOne.com), or on Twitter@smthatte.
Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 6, SEASON 6: DECISIONS, DECISIONS
[Introduction] Sharon and Diana love helping people become effective as teams, and helping teams of people become more effective, especially when it comes to shared leadership and making good team decisions.
[03:15] What makes a team a team? Who and what is the team?
[04: 45] “Cross-functional” means every skill needed to accomplish the team goal is embedded in the team.
[09:50] Lean guides us to ask those closest to the work to make the decisions about that work.
[11:10] Sharon has heard this idea of decision-making since the late 70s – and she believes good managers have always known this. Not a new idea!
[15:45] The worst and most avoidable mistake managers can make is, after asking a team for their perspective, to weigh in with their opinion before listening to what the team thinks. Ask your question and then be quiet.
[22:30] Decades after knowing better as a business culture, managers still seem to struggle with this issue – complaining they can’t get their team’s feedback while jumping in and giving their opinions before they’ve listened to the team.
“Making Dumb Groups Smarter”, Cass Sunstein and Reid Hastie – Harvard Business Review, December 2014. https://hbr.org/2014/11/making-dumb-groups-smarter
“We The People: Consenting to a Deeper Democracy (A Guide to Sociocratic Principles and Methods)” – http://www.adeeperdemocracy.org/we-the-people-consenting-to-a-deeper-democracy/
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
I'll catch up again when I have more time.
We’re delighted to announce that the release of Axosoft 15.1 includes an expansion of the All Items tab! Before we jump right in, feel free to check out our list of defect fixes. Otherwise, here’s a breakdown of what’s new:
- Add any item type under All Items
- Rank all your items together
- Apply your Filters to each item type
- Export from All Items
- Dashboard beautification
The All Items tab now has more of the same functionality as other item tabs. For example, you now have the ability to Add any item type. Just make sure you specify the item type first:Options abound!
Editing also behaves the same way as any other tab, though the multi-edit is where the All Items tab now shines. Multi-edit items by selecting the items you want to edit and then clicking the drop-down arrow to the right of the edit button. If the fields are shared then you can update them all at once! The pop-up window will communicate what fields are shared between the item types selected.Some fields will overlap while others are unique to just one.
Ranking is now available for All Items. Hit the down arrow icon to call forth ranking and enable your filters (see how in the next section) to only see your relevant items. Now you can rank your bugs, features, tickets, etc. against once another for a given project or release.Rank your bugs, features, or incidents against one another.
Filters are now here too; how do they work you might ask? Well, each item type will have filters for each item type as shown below. The filter you enable will only affect that item type. For example, if you want to only see features that are not closed, and you want to see them next to all your bugs and tickets, then enabling the “Not Closed” feature filter will do the trick.Filters for each item type are now available.
Export all the items! You can now export your data from the All Items tab into a .CSV spreadsheet. Just like every other tab, this will be found under the More menu of the All Items tab.Export from the All Items tab or click the print button right next to it to print to PDF.
Ah, card view is now available from the All Items tab. To change the workflow of the cards click on the workflow columns drop down and choose your workflow. Notice that there are multiple workflows to choose from. Pick the item type and workflow you want to change. You are then free to move your cards through their workflow.Card View is here for All Items.
The details panel is now more robust as well. You can view custom fields, subitems, and source control types. Fields that are not applicable to the item type you have selected will display a message. You can also edit what items are showing in the All Items tab from Tools\System Options\Details Panel.
Aside from the All Items tab, there are a few bonus features. First bonus, you can now also add images to the release notes by clicking on the release and then edit.Paste away!
Next, rich text formatting is now available for default text in large text fields. Your default text in the field template can now be formatted to your heart’s content.
Lastly, the dashboard received some style love and has a fresh new look.So crisp. So blue.
That wraps up what’s new in 15.1! Feel free to let us know your thoughts in the comments or via Twitter.
“Teamwork is the secret that make common people achieve an uncommon result.”
Ifeanyi Enoch Onuoha
While working in an agile environment teamwork is a must. As we mentioned in our previous post, almost all software projects are collaborative projects. This is how it works – for instance, if a team doesn’t pull together, people get frustrated. As a result (without a shadow of a doubt) the software they produce will reflect this.
We need to remember about an agile approach that indicates simplicity – it’s all about people and communication. The team needs to use proper tools, be well-managed and last but not least – need to know how to communicate properly. Moreover, in order to achieve uncommon results all team members need to not only work in an efficient way but also need to be a good, strong team that is based on mutual trust.
We can’t forget about yet another very important factor – the team work environment should facilitate an opportunity to develop a team spirit.
So how to build an agile team? For sure, you won’t be surprised if I’ll tell you that it’s not a simple question :)
Anyhow, despite the fact that it can be a really tough task, we can still follow some rules that can help us with creating a good team, that runs like a well-oiled machine. Thankfully, we have some hints for you!
1. Create opportunities and space
In an agile environment meetings like daily stand-ups or retrospectives are a great occasion for people to get to know each other better. Of course, probably the best way to do that is to arrange an integration meeting somewhere outside the company. This will provide, so to speak, a less formal way to pull the team together :) People will share their stories, hobbies and so forth. As the people on the team hear the stories, they get a better insight into a teammate. It may sound like a truism, but it really works!
In “Overcoming the Five Dysfunctions of a Team” Patrick Lencioni proposes a simple, yet very interesting exercise. During a meeting, each team member tells a story about a challenge that they faced in the past. Of course the leader or responsible person that runs this meeting should take care that everybody feels comfortable enough and assure that nobody is forced to share something that is too personal. The aim of such activity is to practice being open with teammates. This creates an opportunity to grow a mutual understanding and empathy.
Why not think about other ways to create a social glue among the team? Have you heard about the principle of work in one room? The whole team tremendously improves communication and makes many previous procedures become unnecessary.
That’s why it’s important for the team to adopt their own space in their specific way. Open space is a really good idea because it’s hard to build an Agile team when people are segregated (like testers are in one room, developers in another etc.). Although there are roles in the team, there is no such thing as a hierarchy.
In an agile way, we can speak about the “whole-team” approach. Such an approach stresses the importance of the team – “all hands on board”! The whole team is focused on delivering high-quality software. This kind of approach entails constant collaboration and communication among the people. Work in one room creates a lot of opportunities to make things happen!
And what if the team (for many reasons) can’t seat in the same place? Well, we will cover this topic later on. So keep on reading :)
Here we go with another idea – why not to think about having lunch together? As Liz Sedley wrote:
“Eat lunch with the team whenever you can. Listening to the team in an informal setting helps you understand team better. You’ll find teams often talk about the problems they’re facing over lunch – in a way they wouldn’t at a retrospective. (…)”
2. Have specified goals
Tony Robins said that “Setting goals is the first step in turning the invisible into the visible”. Spot on Tony! Once we have a great, motivated people we’ll need to set reachable but still challenging goals that give a sense of direction to the team.
This part can also be a tricky one. It goes without saying, that if we set too easy goals to achieve, the whole team will get bored and most probably demotivated soon. However, on the other hand, if objectives will be unattainable and out of reach it can paralyze everybody. That’s not what we want to achieve right?
The key thing is to create goals with accordance to the following rule: Not Too Easy, Not Too Hard. People like to be proud of their work so keep on setting challenging objectives. Let’s focus on building the environment where a team can demonstrate creativity, ingenuity, and team spirit to resolve problems in their own, agile way.
The big goal or the big picture is to create valuable and great software. But what does it mean to set goals in an agile way whatsoever? It’s all about the context!
You’ve probably heard about the SMART rule, haven’t you? It says that goals should be Specific, Measurable, Attainable, Realistic, and Timely. So it’s a great rule, but sometimes it’s not very sufficient. Keeping in mind that agile is about being flexible and adjusting to a current situation (can be changed if needed) we can use SMART rule and adjust it to our agile approach.
S - Specific:
What do we want to achieve, How do we want to achieve it and Why do you want to achieve it?
M - Measurable:
What cannot be measured cannot be managed. How will you know that you’ve reached your goal?
A - Attainable:
The goal should be challenging and encouraging for you to do the hard work.
R - Realistic:
Although the goal should be challenging, it should also be realistic.
T - Timely:
When will we achieve this goal?
With regards to what was written before – we can use the SMART rule only when we become aware of the context. What does it mean? It means that sometimes we will have to pick a few criteria that will be important to our current situation. Let’s write it again:
- it’s all about b e i n g f l e x i b l e !
Agile goals can easily be modified if need be – changed resources, budget, energy or time.
3. Choose the right tool
Working with a proper tool that meets team expectations is a very important factor. The team should also have some space to explore the new technology and to experiment with new software and solutions that can make daily work much more effective.
A good old team-board helps to keep important things visible and it’s still widely used among a lot of companies. It’s ok to work with a board, but it’s not sufficient. Do we have an easy and quick access to the history of changes using a board? Nope. Can everyone involved in the project can look on the taskboard or backlog from any place any time? Nope.
Nowadays it’s pretty common that people can work in distributed teams all over the world – working remotely. Nonetheless, such teams still have a lot of successes! How do they do that? By using proper tools.
So, as you can see a traditional board that hangs somewhere on the wall in a team room may still leave a lot to be desired. Therefore, the key is to use a smart, agile collaboration tool that is reliable, clearly designed and easy to use. That’s why we’ve created tinyPM:
“Lightweight and smart agile collaboration tool with product management, backlog, taskboard, user stories and wiki. Web-based and internationalized.”
It’s extremely important that the tool you decide to use with your team is ready for customization via opened API. This feature is a must! Just like a wide range of integrations with other tools. You can find a lot of great integrations with tinyPM:
- You can connect it to Slack in order to stay in touch with every change that was made in your project
- Or link tinyPM with your GitHub: When you push your changes to GitHub, it will forward your commit to tinyPM.
- and much much more! Check out all integrations here.
“Coming together is a beginning. Keeping together is progress. Working together is success.” H. Ford
Building a team isn’t an easy task. As a matter of fact, as we’ve already agreed – it can be very tough. Nonetheless, it’s worth to put as much attention and effort to constantly improving your teamwork and increase the team spirit. Despite all hurdles and problems that will follow somewhere along the line, just remember that teamwork is the factor that will help you to win the game.
In his book, Blink, Malcolm Gladwell tells the story of marriage counselors who can tell whether a couple will stay married or get divorced after watching a very short video of the couple talking. The researchers have been able to spot subtle signs of contempt that would eventually lead to divorce.
When it comes to scaling enterprise agile, organizations have their own subtle signs of contempt, things I (and any other person, really) can observe that would lead to the conclusion that any attempt at agile will not have long-term success in that organization. With issues that cut so deep, trying to scale them will fail.
What is that sign? What do companies do that sabotages their attempts to improve?
The answer is simple: teams.
More specifically, it’s how organizations treat their teams.
If you have truly cross-functional teams that stay together, empowering them and allowing them to learn from each other and proceed through the stages of team development, then your chances of success will be very high. True teams, with trust, a sense of commitment to each other, and the ability to develop a sustainable pace of delivery, will lead your organization to bigger and better things.
Conversely, if you treat teams as mere boxes into and out of which people are shuffled, if teams are built up and torn down when the priority of projects change with the direction of the wind, and people are not allowed to stay together long enough to form bonds, you will never succeed.
I know, I know; that seems like a pretty dramatic statement, but it is true.
You will not succeed.
You may have some short bursts of “success” that come from heroic project work and a few rock stars, but that is not sustainable. Do not let this “success” fool you. You are not creating sustainable teams that will be able to constantly deliver valuable software.
It is not just keeping teams together; they must be truly cross-functional. Many companies are still holding onto the old vestiges of shared services models or “component and feature” team models. These will work, but will dramatically cut into your ability to scale.
Simply put, your ability to scale will be limited by the shared team with the lowest capacity. It does not matter what that shared team provides; I have seen it in many different flavors: security, EDI, data warehouse, and other internal specific applications. Whenever you lead yourself into believing these teams are “special” and need to be separate from the others, it will be difficult to scale.
Let’s look at a couple of examples.
First, we have a shared team that is supplying work to the feature teams. Notice how all of their velocities are similar (velocity scores are in the circles). The primary reason is that the shared team is holding them back. The teams are fighting for the scarce resource (the shared team) and waiting for deliverables from that team is artificially throttling their velocity. In other words, they could go faster, but cannot because of the bottleneck.
More troubling, if you have to focus all of the teams on one important goal, you would not be able to achieve your goal as fast, and their velocity would most likely drop due to their reliance on that shared team.
Now let’s look at a development group with truly cross-functional teams. First, you will notice that the overall velocities are higher, mainly because there is no shared team throttling their work. Second, if you had to focus all of the teams on one goal, all of the teams would be able to drive in that direction. No one team would become a bottleneck, and all are contributing to the goal.
So… how do we create cross-functional, sustainable teams?
First, know that it is not easy. It takes dedication, empowerment, and a top-down willingness to make it through the transition. We know from Dr. Bruce Tuckman, a researcher into the theory of group dynamics, that teams will struggle in the beginning. As they are going through “forming and storming,” productivity will crater. However, your patience will be rewarded once they normalize and then reach performing level.
Second, don’t be afraid to take risks with teams. Blend your “A” players with some junior people. Teams of all “A” players tend to linger in the storming phase as everyone is trying to be the alpha dog. Maybe let the teams choose themselves (just beware of the playground last-to-be-picked problem).
Finally, break up any cliques. Especially if you’re moving from a shared service model, those folks will most likely want to stay together. Why? They have been a team! But you need to spread their skills around (remember, we want CROSS functionality), so they need to find new teams.
The lynchpin to being able to consistently deliver great software is the empowered cross-functional team. They are the foundation of predictability within an organization. Without sustainable teams, executives tend to fall back into the “just get it done by X date” model. This model only serves to burn out the people and does not help the organization to achieve its goals. Building a solid foundation of teams takes time, effort, and patience, but the rewards greatly exceed the cost to get there.
Find out how VersionOne empowers successful teams with TeamRoom.
We’re always looking for cool new things to work on at Axosoft and this culminates annually in our 30-day-projects. In last year’s 30-day projects a bunch of us started working on a new way to interact with git.
One of the things we wanted was a tool that was cross-platform. All of us have different working styles and none of us want to compromise the quality of our tools. So we decided to try something new and different; we decided to make a cross-platform git app using some cool new technologies. We looked into building a git client using nw.js (formerly node-webkit) and Angular JS. The one critical thing we needed was a node module that was cross platform and allowed us to access git.No good cross-platform git options…
During our 30-day project we decided that our app shouldn’t require a user to have git installed on their machine. It should be completely independent from other 3rd party applications that most git clients rely on (e.g. msysgit/putty on windows and git/OpenSSH on OSX/Linux).
The best option we thought was using libgit2. This is a low level C library that is 100% cross platform. Unfortunately, there were no good ports of this library to Node.js. All of them required some additional work to really get off of the ground. We decided to move forward with a UI demo of our app and if there was any interest, we would come back and try to solve the more technical issues.All systems go!
After showing off our UI demo at the end of the 30-day project, we got an overall really good response. So Axosoft decided to start backing some of the technologies that we would need to actually bring a product like this to life.
After looking through all of the ports of libgit2 we eventually settled on NodeGit. We reached out to the maintainer of the project Tim Branyen, to see what needed to be done and where we could help. He directed us to help write some of the code that automatically generates the Native Node Module in C++ that wraps the libgit2 library using the supplied libgit2 JSON file from the libgit2 docs page.Wait what?!?
Yep, NodeGit generates itself. We have some code that we’ll feed some JSON into that will spit out C++. Pretty cool huh? I could talk endlessly about the crazy stuff we needed to do to pull that off, but I think I’ll save that for another post.So what the heck is NodeGit?
NodeGit is an asynchronous native node module that lets you call into libgit2. That means that a node project that uses NodeGit can do low level git commands without assuming anything about the machine it’s being run on! It even handles the SSH credential auth! On Windows!!!
You don’t need msysgit or a specific version of git installed. Now that would all be handled for you in this neat little libgit2 wrapper. Not only that, but it’s super fast (and going to get faster) not to mention, it doesn’t block for I/O. That means that your app stays super responsive even while cloning large repos or doing anything else.Big names are already using it!
Any given day we have over 80 people idling in our gitter channel. NodeGit is now being used, or is planned to be used in more and more projects, including Microsoft Azure, GitHub’s Atom editor, Netflix, PayPal and more. We had 7.7 THOUSAND downloads off of NPM in March 2015 and we’re on track to exceed that in April. We’re the 2nd most starred wrapper project for libgit2, beaten only by Rugged, which is what GitHub is built off of.
I’m pretty proud of how far NodeGit has come since Axosoft decided to back it a few months ago and what our awesome team has been able to pull off. I think this project can really drive better git integrations, more complete git clients and help the community create amazing tools leveraging git. And I’m really excited to see what you can do with it as well.
Happy hacking and if you get a chance, let us know what you think!