I recently saw a graph from The Standish Group quantifying that only 20% of all delivered software features are “often or always used.” This is a pretty staggering statistic to take in, considering when I think of this in light of what my client is building right now for their customers. Could it be said that only 20% of our effort is used??? Think about that for a minute!
What we could do is to completely elaborate, build, test, or document our releases so we can, when looking back, see what was most important to the user… but this would be too late…
Beginning an journey in Scrum can be as exciting as any new endeavor that we begin in life. It can be exciting as well as overwhelming.
A good article I recently read had given me a fresh perspective on this, and with any type of self-improvement, it is valuable for us to self-reflect on how this new improvement is really going to help our lives.
There are many different types of Agile tools out there. Some are free, some are paid, some are going by the new business model called “Freemium” in which you get a distilled version of the software but to get all the awesome features and scaleability you have to pay.
We’ve talked about before how important product owners are in the whole agile process. This is still true. This will always be true!
These product owners are Very Important People as the PO is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. They are also the ones that set the priorities for the team as well. When there are changes in requirements, the PO continuously makes the decisions and gives the latest information to the team about the changing priorities. Development teams are always asking the questions: “What do you want me to build? What is the business priority?” – The PO tells us!
Philosophical conversations over lunch or coffee often lead to a lot of thinking about our current situations and clients. I sat down with a client over lunch and our conversation steered toward our team, and how it there are so many dependencies hamstringing the project currently. From technological and systems issues, to specific coding knowledge of certain individuals, and even dependencies on time zones. It got me thinking about how dependencies truly affect development and our basic assumptions about them.
Sometimes it’s great to sit back and think about your value. A little bit of self-introspection is good from time to time.
I recently listened to a speaker who talked about the value of time, saying that, “It wasn’t about what time it is, now, but rather, how much time you have left.” – His point was made clearer towards the end. Prioritize your life. What is the most valuable thing we should be pursuing now?
Well to grab onto those thought-strings for a bit, it made me wonder. What about my value?
“So, we’re doing this agile thing, correct?” / “So, my understanding of agile is…” – Typically I know where these questions are going, and usually they are from the individuals who have not had the greatest experience in agile. But, I’m glad they are asking me!
After having a healthy discussion with a couple of business partners and friends about agile and the enterprise, we found ourselves discussing a couple of some of the most heard questions (like the ones above) from clients surrounding their understanding of agile.
These are great questions, trust me, I get plenty. I don’t have an answer for every question, but certainly asking questions helps elicit a conversation about how we can help.
With any client that I work with, when we look under the hood at the current software that they have been building there has always been a crap-ton of code that has been passed over, saved for later, or just commented out. This does not include all the extra pieces of code that just sits around all over the place! One of the many issues that a development team must start to think about is how technical debt adds up.
Technical debt is anything that should have been done as part of a development process that did not get done. This includes Test Cases, bugs that were not resolved, un-refactored code, and missing documentation. This debt is like any other debt – you keep paying on it. By incurring this debt, the team, and systems are mortgaging our future.
This post comes from an issue that often comes up from time to time with development teams, whether explicitly or implicitly. Regardless, it needs to be addressed.
So, at the end of each iteration we’re supposed to demo and retrospect our code, correct?
This implies that we have working software at the end of each iteration, right?
Even if we don’t, how do we measure that the software is ‘working?’ Do we define it through the fact that our critical test paths work and the code is a flawless victory? Or should we look at how we define ‘working?’
Let’s look at a website for example:
Does the dot com work? – Yes of course it does
Do users like it? – Yes, it seems that most find it very useful for their needs
What if we had a spike of tens of thousands of requests at the same time? We may have some application degradation and loading issues. Should we have metrics to incorporate load as a measure of our success?
Maybe you can think of a measurement of success that we’re not looking at currently. Our code may be good, but is our software truly working?
Sometimes it’s easier to look at issues by defining what they are not, first.
Not Good Measures of Working Software:
Meeting specifications. Often the specifications have fatal flaws (we saw this in some of our specs for pricing changes)
Revenue. A market fluctuation affects revenue and is not a true measure of whether the software works (what happens when RH conversion goes up 4% within a week seemingly random)?
User surveys. Users often change their minds about the same piece of software (Our removal of the feedback link).
What would be some ways to measure our success of your software today?
For big product launches, design is absolutely imperative to have done well. Hopefully, where you are working, you have a product management team, product owner, or marketing team that knows exactly how the product, system, or website needs to look like and they have a pretty darn solid way of showing it: wireframes, or design specs, etc.
Hopefully, even, they may have these design requirements all spec’d out even before you begin looking at it or creating stories! But often, they don’t. So how does design fit into Scrum when developers are demanding to have wireframes and sometimes, even, the whole daggum thing designed-out before they can begin work (I think this can be unrealistic).
I like to start with an “Iteration Zero (0),” a design iteration that takes into account time to wireframe, speak with stakeholders and involve a development lead to give some insight into how the system architecture may or may not be able to handle some of the design requirements.
The developer must be able to take something from the design meetings and the design specs/wireframes/design requirements must be just good enough for the developers to start work on. This has to be a healthy balance between what is needed by the developers and what can be fleshed out by the product owner and designers.
With my current client, we’ve found that if we take a test driven development approach (building out test cases and use cases) we can easily fill in the design aspects as we create modules or stacks of the whole. Woah there, it’s looking iterative and agile! So what we have here is a piecemeal development process that starts with the conversation with the product owner and designers (who also build test cases), and chunk out the whole development into design stacks that can be consumed by development.
Bottom line? Design needs to be just as iterative as any other agile process. There needs to be frequent inspection and adaption of the system as it’s built out. For a more detailed look at this check out this link here: [Agile Design].
Our new business cards have been printed and hit our doorstep. Props out to PrintRunner.com for the awesome job!
The benefits of having a small consulting shop are that we can have cool cards like this and not only that, but consultants can customize the look and feel per their own design inspirations.
If your business is looking for some great business card printing services, then don’t delay hitting up PrintRunner.com. Fast and efficient!
We’re looking forward to dropping these as we’ll be getting ready to sponsor IT Week at CBeyond next year. We here at White Barrel love to give out free swag. Maybe we’ll drop an iPad or something else???
Whenever I meet with a client and we get to talking about how the resources are allocated and how many members of the team there are, invariably we’ll end up talking about how the team is situated logistically. It’s always readily apparent to me that an organization or team is ready and willing to adopt or embrace agile practices if it is willing to have it’s environment shift and change as well.
I know, I know, we are people and creatures of habit, yes. But if the primary focus of a development team is to provide value to the customer, then shouldn’t we be acting (sitting) in a way that would be conducive to that? I mean, isn’t that the whole purpose: to enable us to provide as much value as we can?
Well, not only that, but communication is key as well in the agile office. We want to make sure that we have open lines of communication and remove the barriers to effective collaboration as much as possible. As I see it, the agile environment is an anti-cubicle farm. A couple of points to note when moving to an agile workspace:
Team members are in close proximity to each other, preferably facing one another
There is a centralized team area where most of the work is done with privacy areas for individual “heads-down” work or personal time
Walls are used to posting notes, displaying charts, graphs and the results of brainstorming
Team members should have easy access to whiteboards or charting paper to collaborate quickly and effectively with team members
What happens if you can’t get everyone in the same room? What about off-shoring? This can be a learning process in that regardless of where your team members are located, the essential goal is to deliver value to the stakeholders. One can accommodate distributed team members as long as all adhere to the principles of collaboration and consciously learn from the process. Some practices will work, such as teleconferencing and webcam conferencing, but there Is no silver bullet. If something doesn’t work, try something different. Eventually each work environment can achieve agility and productivity as the team narrows down what works and what doesn’t.
Recently, Seth Godin published a blog post on self publishing and why (for him at least) it is worth going the self-publishing route. Hey, this isn’t meant for everyone, but if you’re interested in the article you can find it here.
What is funny is that I read a rebuttal blog entry that really outlined the reasons why someone may not want to take Godin’s advice. I found myself reading through the entire article and wondered to myself, “Hey, should I go a self-publishing route for my book?” Maybe so, maybe not. For a link to this article you can jump here.
The biggest reasons that it may seem beneficial for me to self-publish would be the following:
1. I get to control the publishing process as well as the marketing and media.
2. I get to design it any darn way I want.
3. It gets my thoughts and ideas out there quickly.
4. I can use the self-published book to jump start my other book ideas that I have in the works.
5. I get to have a cool tangible textbook of my work (COOL FACTOR+++)
We’ll see which way I go. I’m getting used to finding rejection letters in my email box. Here is a recent one:
Thank you for your proposal. At this point in time we are not interested in pursuing this opportunity with you. Thank you for thinking of <Publisher Name>.
Continuing from my previous post, I wanted to talk briefly about employee reviews. I absolutely love Dilbert comics and I had found this comic that solidified my topic for this post.
If you are in a leadership position for an agile team and you also hold the responsibilities for doing employee reviews, you have the opportunity to hold your team to the highest standards as well as allow your team to hold each other to the highest standards.
The review process is as follows:
1. Project Retrospectives – These retrospectives are held monthly by the team. Organized by the team and supported by the team. Developers can often be very blunt and very vocal about the good, the bad, and the ugly. A team can take advantage of this. These monthly project retrospectives is an opportunity for the team to review itself, team members, and what we can celebrate, and what needs changing. Often times, the feedback can be very positive, and sometimes, the feedback can be brutally honest. If someone isn’t pulling their weight, or has consistently been a ‘blocker’ for stories, or productivity, that person is called out. Team members want the best, and should be supported by management to want the best on their team.
2. 3 Month Project Reviews – These reviews are, again, held and organized by the team. In my experience these have been the reviews where the team can vote a consultant or team member off the team. Sounds harsh? It is. In one of my experiences we went through 4 contractors in 2 months and finally landed on a team member that was up to par with the work ethic and excellence that the team demanded. Lots of turn over? Yes, possibly? Will you end up with the best team you can get? Absolutely.
3. Yearly Reviews – These are your standard reviews by management. Hopefully, prior to this you (management) has had individual sit down time with each team member to go over their goals for the year. These goals should be written by the developer, and a conversation about timing, expectations, and outcomes should follow.
In my experience, this voting of a team member off the island has been crucial to the success of the projects I’ve run. Now, I’m no guru or expert on reviews, but this seems to have had some good outcomes in my experience.