Guest Blogger Vince Mills

In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. One large company’s confused finance department expenses all agile software development and capitalizes waterfall development; projects in this company that go agile see their headcounts cut by 50%. This discourages projects from going agile.

Scrum’s production experiment framework can align well with the principles of financial reporting. In this article, the author explains the basics of capitalization and expensing, and offers a financial framework for capitalizing agile projects that can be understood by both accountants and agile teams.Software development is an investment in the long-term future. Some software development projects are not long-term investments; it depends on whether the software remains an asset. Agilists should learn proper capitalization and teach their colleagues. Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development correctly.Companies can gain tax advantages by capitalizing software development; by deferring costs they typically offset more taxable revenue and gain more interest income.Corporate agilists need to help finance departments capitalize agile software development properly. ScrumMasters and agile department heads who understand capitalization and depreciation can generate millions in tax savings. Responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.Because recommended accounting practices ignore Agile, the article discusses how to classify costs as capital or operational expenses and gives guidance on how to make the transition from waterfall to Agile in a way that pleases management, accountants and auditors.Making the case for agile capitalization will reduce your company’s tax burden, increase available funds for engineers, and make your auditors happy.

First, is a Scrum Team organized?

Well, a good Scrum is more adaptive, probably, than it is ‘organized’.  Of course, we can debate the meaning of these words, but during a day or during a sprint, or during a release, I usually would rather that the Team be adaptive, than that they follow an organized plan. As one example.

This is one small reason that our Scrum course is not organized in a strictly logical way.

Second, why do Scrum Teams fail?

Well, there are many reasons. One key reason that is not true: They were not intellectually able to fight through the complexity of the explicit knowledge around the bare framework of Scrum.

In fact, the bare framework of Scrum is very very simple. (On purpose.)  And understanding the explicit knowledge around that is quite easy.

Hence, we are not worried that we need to organize the course so that the attendees build in their minds ‘complexities upon complexities’ about Scrum.  If Scrum were complex, for example, like the Calculus, then we would have to organize the course a different way.

Again, Scrum is ‘holistic’ or interdependent.  One cannot understand one part of Scrum without understanding how it works with or plays with another part of Scrum.  ‘No man is an island’ as John Donne famously said.  So, we like to continually weave from one thing to another, so that this weaving starts to be embedded in the ‘back’ minds of the attendees.

So, one of the key problems is tacit knowledge. Getting the tacit knowledge and all that that means into their heads.  But, honestly, not just into their heads, but their hearts, their souls, their guts, their bodies.

And one of the big problems is that the attendees, or many of them, resist intellectually.  So, as in Zen, we have to confuse the intellectual mind in order to enable real learning to happen faster.  Or, as the Army says, we have to break them down in order to build them back up again.

We have to ‘go around’ or ‘get behind’ the intellectual resistance that is common to just about all of us. So, one technique is to do exercises. But not following a highly logical flow to the course is another technique. Surprising the attendees (in small ways) is another technique. Humor is another technique.  Improvisational exercises is another technique. Food is another technqiue.  Addressing them, and getting to know them, as a person is another technique.

For some, our techniques (and there are actually many) are…umm, disconcerting. If one is the organized, intellectually rigorous, ‘it is all about thinking and logic’ type of person, it can feel a bit uncomfortable.  But if one has at least an intellectual understanding or some real experience that says that people and real life do not always follow our pre-conceived intelectual notions, then it is not so uncomfortable.

So, I admit that the course to a new person, or at least a few, can feel uncomfortable. (Actually, my impression is that most people enjoy it. About 95%.  But not all.)

If, in the course you tell me you have that feeling, then I will offer some advice. First, that we will address the topics, or most of them, that are on the one-page (two-sides) outline of ‘Scrum’ we hand out (it is really more than just Scrum).  And we will follow, mostly, the outline on the website. (Except not in that order.)  And that we will follow the slides, pretty much sequentially.  Except that we will cover additional things that are not shown on slides.

We have a strong confidence that most real learning is not logical. It happens in the sub-conscious mind, where a whole bunch of experiences are ‘put together’ by the brain into a ‘logical’ way of looking at the world.  Assembled into a pattern or set of patterns. And we are forcing your brain to break down old patterns, and rebuild all that ‘stuff’ into new patterns. And we have a strong confidence that all of out attendees can do that.

And we also know, sadly, that many are so much ‘controlled’ by what we call ‘waterfall ideas’ that they will not be able, after only 2 or 3 days, to really replace the waterfall patterns with agile/scrum patterns.  So, we are sad when we do not succeed in this way.  It does happen.

Would we succeed better if we presented things in a more organized, more logical way?  Well, in a very small sense with a very few people, they might at least say ‘it was a good logical presentation’.  And they, that small group, would feel better.  But we are completely convinced that, if you look at the overall results, we would be much much lower.

Remember that our goal is not teaching. Nor learning. Nor even action by the attendees. Our goal is to achieve real results with Scrum. For the person, for that person’s team, and for that person’s customers. One never will achieve real results with merely a ‘logical understanding’ of our work.

We are not after explicit knowledge. We are after ‘a sense of urgency’ and the tacit knowledge that leads to successful results.

I wish you every success in having fun in achieving real results.

I participated in Lean Startup Machine in Sydney in April 2013.  Here are a few things I noticed and thoughts I had...
Three customers Sebastien Eckersley Maslin, CEO of BlueChilli, talked about his 3 customers concept:

1. Target Customer: Who has the direct problem you're solving?
2. Scale Customer: Who deals with your Target Customers in bulk?
3. Strategic Customer: Who can derive more value from your assets than you can?

This was from the perspective of exit strategy which I generally don't care for.  However, this concept is still interesting if you see this as a way to understand the bigger picture of what happens when a product / service is introduced in a market place.
What's your larger mission? Jodie Fox, co-founder of Shoes of Prey, pointed out the importance of having a larger mission, even a potentially impossible mission, but one that provides a consistent direction.  For example, for Shoes of Prey this is "Every woman deserves a perfect shoe".  This was in response to a few teams that had "pivoted" to perhaps not as interesting concepts.

This reminded me of The Toyota Way and the importance of having a Long-Term Philosophy.
Teach a way of thinking or find another successful startup? Is the purpose of events like Lean Startup Machine to teach a way of thinking? Or is it to find another successful startup?  I believe it really should be the former.

Structuring as a competition does not reflect that purpose.

Instead of a competition, the event would focus on teaching concepts, basic assumptions, principles, and tactics like Magic Tests, Concierge MVPs, selling approaches, etc.

Teams would be encouraged to identify problems that could be explored within the context of the event (i.e., on a weekend) AND/OR the event would be scheduled to allow different types of problems to be relevant.

Teams would be smaller so that participants would actually have to attempt all the skills themselves rather than rely on another team member.  Perhaps they would be 1-person teams to ensure that everyone has a direct understanding of what skills you actually need in the real situation, and therefore who you'd want on your team.  People would be exposed explicitly to what their strengths and weaknesses are.
Validation Board or Business Model Canvas? Lean Startup Machine uses a Validation Board to structure our hypotheses and tests.  The focus is on testing problem-solution fit.  I like the focus of the board, but I miss the bigger picture aspects of the overall business model that you can see with the Business Model Canvas or even the Lean Canvas.  I think I'd rather use either of those to capture the overall business hypothesis and switch to a Validation Board like structure after the riskiest assumption was identified.

Pavan Sudarshan

My last gig as a tech lead was on Bums on the Saddle, an ecommerce startup where we had to get a working piece of software with minimal functionality to production within a week. We then had to follow it up with frequent releases and be done with the minimum viable product (MVP) in 8 weeks. After the MVP we had to incorporate feedback and the store’s backend needs. We signed up for all of this and more in a Lean Startup style gig.

Thumbnail: 

read more

The most popular Agile certification! This two day course gives you the foundations to be an effective ScrumMaster and contributes towards the requirements of the Scrum Alliance’s Certified ScrumMaster program. Delivered by Berteig Consulting’s own Mishkin Berteig!

By successfully completing this course you will be able to:

• Remove obstacles that prevent teams from becoming high-performance.
• Enable a team to follow the Scrum process to deliver great products and continuously improve their quality.
• Describe Scrum to others including roles, meetings, artifacts and principles.
• Fulfill the requirements of the Certified ScrumMaster program.

Days: July 10, 2013, July 11, 2013

Location:

Audience: This course is ideal for those who desire to create high-performance product development teams. Team leads, project managers and functional or line managers all can benefit from understanding Scrum’s amazing transformational power and the critical role of the ScrumMaster. If you are a member of the Project Management Institute, this course counts for 16 PDU’s and as part of the requirements towards the PMI-ACP designation.

Price: $1400.00

Contact: Valerie Senyk at 1-905-868-9995

Email: valerie@berteigconsulting.com

Link to Register: http://www.worldmindware.com/Certified-ScrumMaster-Mississauga-July-2013

People have two styles  when they prepare to take action and meet their goals: The "Toward" and"Avoid To".  These were revealed to me by a great chat with Sylvaine, a successful coach of "Well Being at Work" in France. She says that it takes both profiles to effectively achieve the goal. That turned on a light in my mind  it's not only about individual profiles it is also about cultures : they are also deeply anchored in the "toward" or "Avoid To" style to see the wold evolving."Toward and "Avoid To"It is unnecessary to write long essays or boring blog posts to explain what these two profiles are about.The "Toward" way is "get-into-action" driven: look-forward,  never forget what is most important for you and go-for-it. Everything else are details that can be dealt with on the wayThe "Avoid To" way is focused to protect the "route that leads to the goal" of the different obstacles. Forecasting potential problems is a valued activity for the "Avoid To" styles . They like to have the most exhaustive risk analysis as one can get. 
OppositesIf both profiles are helpful to achieve a common goal, the challenge is huge. These two profiles tend to have little natural appreciation for each other. The "Toward" people tend to consider the "Avoid To" people ineffective,  unwilling to take responsibility and somehow... "spoiled" and "lazy".The "Avoid To" people tend to consider  the "Toward" people as bullying, bossy,  somehow ... rude and definitely lacking respect to anyone else in the room.So put these two together to nicely work together, yeah! A piece of cake! And still, let's go for it.
Individuals and Cultures create their personality through stories
"Toward" and "Avoid To" are rooted in our culture and they shape our way to see the world. Beyond individuals,  some cultures value a "toward" posture and others that are more "Avoid to". History is full of examples of tensions between nations that base their culture on the 2 different profiles.  Each group and organization is creating a culture, sometimes without really being aware of.  We mention the "company culture", and we may have some hard time to define it. Just like for different people, what we really have at hand to describe culture are its stories. The most reliable way to reflect a culture are stories.  These stories tell you, among other things,  if the group (company, people...) culture is "Toward" or "Avoid To" driven. Here is a little example:
The Salt Block
A very popular Romanian tale* starts like this :

"Once upon a time there was a young peasant . He was happy : he worked hard the land and the land was generous to him. He was married to a young loving woman that kept the house bright and have filled his life with joy when she gave birth a couple of weeks ago to their son, who was strong and in good health.
That summer sunny day he was coming back home from the labor of the field, when he hears scaring cries in the house. Full of panic, he hurries home and enters the house. His surprise was not little when he sees his young wife and her mother bounced over the baby's cradle, crying out loud as if the baby were dead. For God's sake, the baby seem to be in perfect shape , only scared of womens' cries.
"What is happening here, women?", asks the young man
"Oh, my dear husband,  a cruel fate is threatening our son!"
"Oh Holy God", says the man who starts to be really frightened, "what is that?"
"You see the big heavy block of salt on the top of the drawer?"
"Well yes..."
"And the cradle that is near the drawer right under the block of salt?"
"???!!", the young man's fright turns into perplexity .."And...?"
"Well you have a heart made of rock, you, what if the salt block falls on our baby and kills him?" cries the young woman that surrenders in the arms of despair.
The young man is shocked by his wife's stupidity. He decides to leave home and never  come back unless he finds people in the world that are more stupid than his wife. 
What does this story value? Would you recognize one of the two profiles here? If you think you have the answer, wel, actually, it might not be that simple ... 
You can change only one person : Yourself
If you'd ever want to know what is the end of the story, I'm not sure there is any English version available, so let me tell you that it has a happy end : The young man is coming back home, he encounters a lot of people that have a ... more astonishing way to approach life and work than his wife.Beyond reflecting a "Toward" profile , this story's insight is about learning to live with the others, even if you start by don't having a clue about their behavior ( even feeling a hard disapproval about it) . The "Toward" and "Avoid To" profiles are opposite. And honestly they don' appreciate each other.  Making the two profiles working together is not about a super-wonder "someone" above taking some smart move to make the mixture work, it is about myself (yourself) realizing the gap in seeing the world as it is. And trying to respectfully live with it. Just like the young man that came home and lived happy ever after with his family. As long as historical research reported, there was no dead baby ;-) .
Thank You
Many thanks to Sylvaine that inspired this post. If you can read French, you'd really love her blog 

*The original name of the tale is "Prostia Omenească" by Ion Creangă

“You’ve not only made things better, you have truly changed our lives.”

These are the words that every agile coach yearns to hear from the people they work with. While it’s always a goal of mine to change the mindsets of clients, I have had mixed results over my five years as an agile coach. On one six-month engagement with a client I’ll call Prosperity, though, something transformative took place. I’ve spent some time since then thinking about what made those six months so successful and why Prosperity continues to push the envelope of what it is capable of doing as an organization.

At first, I thought it was all around the process. Prosperity, like many other clients, started out wanting to “learn agile.” Teach us Scrum, help us start out right, and let’s roll out agile across all teams, were there primary requests. So I started with what I considered at the time to be a “perfect” way to rollout Scrum to teams—a two-week “Sprint 0″ approach of training, workshops and preparation for sprints that is consistent with every team. I have used this approach with many clients, with varying results. At Prosperity, though, the teams really took to it; they loved it and felt it was going to transform the way they worked. While I can say that all the teams at past clients benefited to a certain degree and were ready to work in sprints at the end of the rollout, I definitely didn’t get the feedback that this was somehow life changing. In fact, from some clients, I got the exact opposite feedback— that this was too process heavy. While all clients saw the results of going through this “kick off process,” none of them had embraced the change to the degree that Prosperity had. So that wasn’t it.

My next thought was that it must be the all around coaching style I had used with Prosperity. I had tried a more directive approach at the start with Prosperity then switched to a more supportive, kind of “back of the room” approach once they started to “get it”—maybe that was the reason why they had responded so well. While I’m not one to usually want to be more directive and in control, I hypothesized that perhaps the key to success at a client is to start out more directive and then back off when the teams are ready. To test my theory, at another client, I tried to be much more directive from the beginning. Bad idea! I almost got fired from the client with that approach.

So if it was not the process, or a specific coaching style, what was it that made my six months with Prosperity so special? Would I ever be able to see the same success elsewhere? The prospect of never having that level of success with a client again made me question whether I should continue being an agile coach. Maybe it was nothing I had done, but just working with the right people with the right attitude. Perhaps it’s not at all about coaching, but about people being willing and able to change given their sheer desire to do something different.

Because that was such a depressing thought, I delved a bit deeper into everything that had happened during my time with Prosperity, both on their end and on mine. In the end, I did find some great lessons on coaching that I believe will help anyone who wants to bring out the best in people.

Agile Coaching Lessons Learned

Lesson #1: Take time to get to know people. Even before I came onsite with Prosperity, I had numerous conversations with some of the key leaders who were bringing me into their organization. I truly took the time to get to know them, how they work, what they value, and what success would look like. In these conversations, they were also getting comfortable with me and were seeing value through the discussion. These weren’t one-sided interviews where I asked all the questions but dialogues, where we discussed thoughts and ideas. Once I came onsite, I spend about 30-60 minutes with leaders of every key team or department within the organization. While I was exhausted after two weeks of these discussions, I was also energized because I truly felt I had established some real connections. By the time I started to engage teams, I already felt I knew most of the team members and that they were comfortable with how I was going to help their teams get better.

Lesson #2: Appreciate their journey and how they got there. I remember many years ago, I started with a new client. During my first week there I observed a team in their planning session. I sat near the back of the room and wrote down my many observations. I was so proud of all the many things that I was finding to talk with the ScrumMaster about! After the planning meeting, I mentioned to the ScrumMaster that I was going to write up my thoughts and get back to him to have a discussion afterwards. I sent him a very lengthy email with all the things he should consider doing differently with the teams and ways to improve the process. The response was not pretty. His response to me: “We need to talk about this.” Never a good sign! When we got together to talk, he started by saying, “You don’t know a thing about us, why we have tweaked the process, why we are doing the things we are doing. So why do you have the right to say we are doing everything wrong?” Ouch! It took a long time to repair that relationship.

Unfortunately, I haven’t always learned from that lesson and tend to come into teams with all guns blazing only to shoot myself in the foot. At Prosperity, though, I did a much better job. I showed true sympathy and respect for their journey so far. They had tried agile before, but with limited success. I asked questions to learn about what had worked and what hadn’t. I demonstrated that I appreciated what they had tried to do in the past, their wins as well as their challenges. I also had honest conversations around their thoughts on agile—fears, uncertainty, doubts, questions, concerns, etc.—to understand where they were coming from but also to show them that I was not trying to change or fix them but truly cared about where they were in their journey.

Lesson #3: Show them a world of possibilities. I used to get frustrated with coming into organizations as an external coach and having clients think of me as the “Scrum trainer,” with the focus on getting the teams formal training as a measure of success. I realized in my conversations with Prosperity, I had begun to paint a picture about what an agile organization looks like. Not with the adoption and training around practices, but around the results that they could see with such an adoption. By painting a picture of what the organization could become, they started to see the picture for themselves and wanted to be a part of such an organization. Looking back, most of my conversations were around “what could be.” They soon realized that there was much more around changing mindset, behaviors, organizational structure, leadership styles, tools, infrastructure, team dynamics and other areas that also needed to happen. By seeing a possible future and appreciating what it would take to get there, people started to find their own ways of owning the vision and making it happen.

Lesson #4: Create heroes that will change the world (and their organization). A few months after I left Prosperity, the president took the time to write up a very nice recommendation. In the recommendation, he had told me that he and others had nicknamed me “the General.” At first, I was taken aback with association—I thought that I had moved on from a directive role to something else while there. To me, being called a General made me think of some guy that stood on a pedestal barking orders to everyone. I didn’t want to be that guy. So, I asked him about the nickname and my concerns about it. His response surprised me, “No, that’s not how I view a General at all. In fact, it is quite different. To us, we saw you as the guy that could see the overall big picture of the organization, where we were going. You helped us move towards the same goals instead of competing goals within parts of the organization. You helped us gain the capabilities to take on the battle ourselves by creating each of us as an agent of change. You wanted us to be successful and we in turn wanted to show you that we could be. Calling you General is our way of showing the highest level of respect for what you did for us.”

Wow! That’s enough positive feedback to make you want to keep going no matter how tough it gets, right? I then realized that if the focus on agile transformation across the organization is strictly around processes, I would fail as a coach. Instead, agile coaching has to be about transformation of people—helping them gather the courage and ability to be a hero and an agent of change within the organization. Get enough heroes and it becomes a viral effect that others want to be a part. Have enough change agents and not only will the changes stick but people will continue to find ways to keep the organization focused on learning and improving.

Lesson #5: Develop a partner relationship. This is not necessarily a separate lesson, but more the ultimate outcome as an agile coach. The agile coaching role is still very new or unknown to many organizations. While I have tried to describe the relationship between a trusted agile coach and an organization, you really have to build the relationship through the other actions mentioned above. If you are truly going to have the relationship necessary to help people transform, you have to gain their trust and respect. They have to see you as not just a trainer but a guide. They have to feel you care about them and want to help them succeed. They need to understand where they can go and feel you can lead them in the right direction in their journey. In many ways, I feel like I have never left this client. I am still cheering from the sidelines, interested in the people and the success that they are having. By becoming a partner in their journey, a part of me will always be involved.

The post Agile Coaching Is (All) About People appeared first on BigVisible Solutions.

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: KNOW THYSELF

“Using self-awareness and self-knowledge for self-management seems to be key in becoming an effective leader.”

Running time 26:38

What instruments have you experienced that have been helpful to you? When has really good self-awareness and self-knowledge helped you self-manage as a leader? If you’ve experienced the Hogan, tell us about it. We’d love to hear your stories.

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – Using assessments in organizations to develop self-awareness and self-knowledge to become effective leaders.
1:55 – Introducing the Hogan assessment – richer, more subtle and provides more nuanced information.
5:56 – The Hogan assessment considers three parts: individual values, leadership potential and challenges or derailers.
13:12 – Comparing the Hogan assessment with the Strengthsfinder by Gallup.
19:54 – One differential aspect of the Hogan assessment – it can be used to map teams.
23:50 – Assimilating assessments like the Hogan in academic programs.

Resources
Hogan Assessment
Myers-Briggs
StrengthsFinder

Photo Credit: Werner Kunz via Compfight cc

I’ve been thinking lately about the ways that different authors explain OOP. I’ve drawn a little diagram that I would like to share with you.

The sources for this are, in no particular order:

• Eric Evans, DDD Reference
• Ivar Jacobson, Object-Oriented Software Engineering
• Peter Coad, Archetypes, Color, and the Domain-Neutral Component
• Rebecca Wirfs-Brock, Characterizing Classes
• Steve Freeman, Nat Pryce, Growing Object-Oriented Software
• Vaughn Vernon, Implementing DDD

Each of these authors has a perspective I find useful. I would love it if there was a comprehensive, single model, but so far I can’t see how to systematize them.

It gets weirder when you start collecting design principles… I might do a mind map of those some day. Somehow I can see how SOLID and GRASP (for instance) are compatible. They are pointing in the same general direction, but from different angles.

I've organized a series of interviews with 11 pragmatic experts on the topic of "individuals and interactions". We'll drill down into what this means in

The Agile Software Engineer is responsible for the design, development, and implementation of services (process and technology) required to deliver business

The Agile Software Engineer is responsible for the design, development, and implementation of services (process and technology) required to deliver business value. You are skilled in problem solving and fearless in exploring both new and innovative technologies as well as weeding through large l ...

  Continuing with the 100 Things You Must Know to Be Effective In Software Development.   I really appreciate the 2-3 new people who commented on the day 0 blog and joined our group. It got me to write today's entry on the flight home from the Scrum Gathering - something I almost certainly wouldn't have done otherwise.  So keep reading and getting friends to join - it helps.   I've been wanting...

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

Presenting to Agile Carolinas: Tuesday, May 21, 2013 from 6:00 PM to 8:00 PM (EDT) CPCC Overcash Center, Room 340, 1201 Elizabeth Ave Charlotte, NC 28204 Space

Recently I have been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common.  In order to get properly account for the costs incurred by software development teams you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn't have to be complex: at one customer developers spend less than five minutes a week capturing such information.

 

Why is Time Tracking Potentially Valuable?

There are several financial issues to be aware of:

• Capitalization. For public companies capital expenses (CapEx) can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization's taxes for that year.
• Matching. One of the goals of good accounting is to accurately reflect the net income of the enterprise and to prevent income manipulation or "smoothing". As such a key tenet is the principle of matching revenues with the appropriate expenses. For software this means that we expense the cost of the software over the lifetime of the asset against the income at that time. An implication of this is that capitalizing software development, when appropriate, before the software goes into production clearly violates the matching principle since there is no benefit of the asset until such time.
• Tax Credits.  In some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.

The point is that the way that a software developer's work is accounted for can have a non-trivial impact upon your organization's financial position.

 

What Do Agilists Think of Time Tracking?

So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) to choose from:

• Yes, this is a valuable activity (33% of responses)
• Yes, this is a waste of time (39% of responses)
• No, but we're thinking about doing so (2% of responses)
• No, we've never considered this (18% of responses)
• I don't understand what you're asking (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity that a developer performs in a given week.

The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:

• It's a colossal waste of time unless you're billing a customer by the hour.
• We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
• I think the *most* pointless example was where the managers told us what we should be putting in.
• One day we will move past the "just do it" mentality and have some meaningful conversations and the reasons for what we do.
• In my experience time tracking is a massive waste... of time. It's a poor substitute for management.
• Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
• Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.

I think that there are several interesting implications from this discussion:

1. Agilists need to become more enterprise aware. It's clear to be really effective that agile delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they're doing.  In Disciplined Agile Delivery (DAD) this is something that we refer to as being enterprise aware.  There's far more to enterprise awareness than understanding pertinent accounting principles, for interest disciplined agile teams work towards a common technology roadmap and common business roadmap, but appreciating why time tracking is a potentially valuable activity would be a good start.
2. Management needs to communicate better.  It's also clear that management needs to communicate more effectively regarding why they're asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they're asking for.
3. Management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).
4. Time tracking should be streamlined.  It was obvious from the conversation that several people worked in organizations where the time tracking effort had gotten completely out of hand.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  Over the years I've helped organizations design measurement programs and I've seen a lot of well-intention efforts become incredibly onerous and expensive for the people they were inflicted upon.  I suspect it's time for a reality check in some of these organizations people were alluding to.  A good heuristic is that for any measurement you should be able to indicate the real cost of collecting it, the use(s) that the information is being put to, and the value resulting from those uses.  If you can't quickly and coherently do that then you need to take a hard look at why you continue to collect that metric.  The lament "we might need it one day" is a symptom that you're wasting time and money.
5. Agile rhetoric is getting in the way.  Some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and stand up meetings may be preventing people from becoming enterprise aware because they believe that all of their management needs are being met by them.
6. You may be missing out on the benefits of time tracking.  Many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

 

Parting Thoughts

Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that many agile developers believe that an activity such as time tracking is a waste when that clearly doesn't have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.

Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more.  But you know what?  Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).

Does your ticket sidebar look like an endless groceries list? Are you looking for a way to organize stories and epics? Are you knocking your head trying to find your way through a sea of tickets?  Then, I think you will be more than relieved to hear that we’ve released Tags for Tickets.

So, go to any ticket view and start tagging. It’s easy. Just click on the edit icon and enter a new tag or select from the existing list.

If you want to change which tags appear on the popup for users to select go to Tickets->Settings->Tag. Select Active if you want a tag to appear in the popup selector or else Hidden if you want to remove them from it.

We hope you enjoy this feature and start tagging right away! Let us if you have any comments or suggestions.

If you want to learn more about Assembla's Ticket and Issue Management System you can read more about it here.

Mingle Team First Place: Hourglass Scrum-Ban Board (Winner of an iPad Mini)

Thumbnail: 

read more

Jade Meskill, Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss:

• When Facilities won’t help
• When Developers can’t set up their environments
• When continuous deploy doesn’t work for marketing

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Serie of article about Sonar installation
By Jean-Pierre Fayolle, 7 April 2013
Jean-Pierre Fayolle continues his series of articles about Sonar installation with 5 new articles:
Install Sonar – The Sonar webap
Install Sonar – Sonar Runner
Install Sonar – First analysis with Sonar Runner
Install Sonar – Jenkins
Install Sonar – The Sonar Jenkins plugin

I’ve had a love-hate relationship with two-phased commits during my years with messaging. Even if MSDTC was free to set up, it doesn’t come free in terms of throughput. Most people run into 2PC in messaging because because queueing systems and databases are two different resources, and therefore don’t participate in the same transaction. Ideally, I’d have all three participants either succeed or fail together:

Since the queues in this picture are different resources than the database, I need to involve a third party, or transaction manager, to coordinate transactions between these three resources.

DTC, when it works, works really well. It’s much, much easier to not care about the consequences of a lack of coordination. In fact, I’d recommend not caring until you actually do care, because ditching two-phased commits does require work. Luckily for us, there are a ton of resources on how to do exactly that!

Most of the time, literature around avoiding 2PC is concerned about an entirely different situation, where I have two separate databases:

We’re doing messaging, which means that it’s typically the consumer of the message that does something against other data stores. So even though we’re avoiding communicating with two databases, it’s still two resources, and thus a need to coordinate!

But again, that coordination comes with a cost. A fairly large cost, in some recent testing we found that overall throughput dropped 80%, or to put it another way, ditching DTC saw a 5X increase in throughput. Five fold!

For some systems, that throughput doesn’t matter much, but for those that have a reasonably high volume of messages, or sensitive SLAs, it’s worth investigating alternative approaches.

General rules of thumb

Like most messaging approaches, the ways of avoiding coordination are right in front of our faces. In Gregor Hohpe’s excellent paper on Starbucks, he points out any real-world system that values throughput over absolute consistency avoids distributed transactions. The basic ideas are:

• Idempotency is king. Get this and you’re halfway home
• Strategies for dealing with downstream effects is a business decision

Idempotency is absolutely required, but it’s not that hard to apply. For some operations, we can rely on natural idempotency. If I’m asked to turn on the light, receiving the request twice means the same outcome – the light is on! For state machine-like systems, idempotency is a bit easier.

For operations that aren’t naturally idempotent (launch the nuclear missile), we’ll need to get a little creative. If we can identify some correlating information from a request (The president called at 9:15 to launch the missile) or just assign some correlation information (The president has issued request #132 to launch the missile), we can simply keep a journal on the receiving side. If it’s expensive to keep a journal around, we can recycle/trim our journals if they get too big.

Downstream effects become more interesting. If throughput is a high concern, we can rely on compensating actions (customer didn’t have enough money, cancel the order) or more journaling. Instead of sending a message immediately, shouting out messages to downstream systems, we can instead just write down in the same persistent store as our other data another journal for outgoing messages.

Once our local DB transaction is complete, it’s just a matter of sending the messages we’ve written down to send out down the line, and crossing them off our list of “sent” messages. And since downstream systems can deal with at-least-once messages through our idempotency guarantees.

How I learned to stop worrying and ditch 2PC

In some current systems, we’re deciding on a service-by-service basis whether or not we want to enlist or not enlist in distributed transactions. It’s still annoying to try and build a system-wide solution (though the event sourcing guys have this more or less in the bag), so until then, I can just use business decisions to guide me one way or the other.

But it is time to let go and stop worrying so much. Honestly, unless your services have downstream side effects, you can safely turn off DTC if your work is idempotent. If you have downstream side effects, there’s a number of paths to choose from. While I’m not saying goodbye forever (still the best solution if it were absolutely free to use), it is time to shop around.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.