I am attempting to answer this question, from the point of view of being a tech lead and also working for a tech lead.

Let’s start simple. A tech lead is a person. well… hopefully we can all at least agree on this. A person, that is a member of a team. This is a key distinction for me… a member of a team… not an outsider, looking in, but a full-fledged team member. Responsible for the success of the team… and still a member of the team when failures occur. More important of these two.. is the ‘still a team member, participating in all repercussions dished out to the team’… when the team fails. And it will happen. Unfortunately, I have been unable to limit my team participation to only teams that have succeeded… Although, I have learned more from the teams that have failed. Not that I wish to continue the learning process forever, but a failure every now and then keeps the soul honest. A ‘good’ technical lead will only consider themselves successful, when the team is successful and each member has been recognized for their participation.

As part of the team… the tech lead will be the person working on the grungy work nobody else wants to be associated with. The type of work that nobody wants to work on, but when done properly… silently… just makes the team better… and multiplies the teams productivity for reasons many will never understand. This will include the continuous removal of roadblocks impeding the process of allowing the team to move at near 100% efficiency. It will also include the process of expanding the technical capabilities of each member, both business and technical. A good tech lead will be able to bridge the gap between the business and the technical. Gifted with the ability to speak ‘technical’ to the technical members and ‘business’ to the business members. This never ending pursuit of expanding the capabilities of the team members will allow the team to continually deliver more and more business value. This will also include the spreading of knowledge among all members of the team… the habit of concentrating business knowledge within a few key people will slow the expansion of business value… the tech lead will force all members to become business experts. The technical staff should be business focused… with the ability to deliver in a technical manner.

In my experience, vision is a differentiating factor between a senior developer and a true tech lead. The tech lead will provide technical vision for the team but will not make each and every decision. They will make sure the team understands the vision but will delegate to the team… letting their own decisions guide the development process. A good tech lead will surround themselves with people they can trust and, therefore… allowing the team members to trust the vision of the tech lead. A sure way to lose the trust of the team will be a tech lead that keeps all of the direction and decisions in his/her head. The team will expect the tech lead to ‘lead’ and not mandate. Reactionary… does not make a good tech lead. A good tech lead should always be ahead of the curve… proactively evaluating the current health of the team. They will work with the team to establish estimates and milestones… not mandating.

Tech leads either shine or falter here. A good tech lead will encourage debate, knowing when a resolution is not possible… listening to the debate and changing the course of the debate, not by mandating direction, but by asking the proper questions… forcing the team to think. A good tech lead will allow themselves to be swayed by the discussions.

Why is that all of the good tech leads are pragmatic? It is not that they do not like to get things done… but there are times to do the right thing (or do something right) and then there are times to just get something done. This needs to be a business decision, not purely a technical decision. Please keep in mind… doing the ‘get something done’ should be because it is the correct business decision and not because you are too tired or just freakin’ lazy to do the right thing.

The tech lead role is more than just a senior developer. It is more than just being able to write a lot of code… quickly. It is knowing when to write code and when to be clearing roadblocks for the team. This communication and silent leadership differentiate the tech lead from the senior developer.

One of the most important differentiators for me is the ability of the tech lead to maintain a relationship with the product owner and the business. This relationship is more than just being friendly with the business, but a relationship of understanding how the product works… and more importantly, WHY !!! The trust that will result, when the tech lead is considered an integral member of the business, will be the ability to push back on business decisions with respect. Many times, the ideas generated by the business will be near impossible to accomplish technically… at least in a timely manner and with a reasonable expenditure. Many times, the tech lead will have the ability to analyze the requests of the business and provide alternatives that are equally as beneficial… with quicker turn-around times and lower cost. It is a sure sign of a less than awesome tech lead that does not understand the product / business problem and only offers constraints instead of solutions.

If you are aspiring to be a tech lead, please heed this one seriously… patience is a virtue. Seems like I have heard that one before from my father. And it has served me pretty well so far. Entering into delicate situations with a calm demeanor will settle the mood of the team and allow for better decisions, as a result. Please do not take this as a one-size fits all… there will be times, when the only solution is to ‘light the ship on fire’… but please remember… this is a last result and when you ‘light the ship’… really do it… 1/2 way will only make you look like you upset. Any interested in knowing what happens… when you ‘light the ship’… please contact me directly. ;)

Feedback… this is a tough ‘thing’ to receive when it is less than positive, regardless of who is delivering the message. A good tech lead will be the first to step up to receive less than positive feedback… whether or not it is directed at the team, at the tech lead or at an individual team member. A good tech lead will deal with issues, but never in an arrogant manner. A tech lead will never survive the role if their purpose is to make the team and/or individuals on the team to feel inferior. A humble personality and the ability to be assertive and possibly ‘flip the table’ if required.

So… summing this up. A good tech lead will possess the following :

• ability to get the team to work together
• technical vision
• ability to discuss and debate, but also the ability to listen and be changed by team discussion
• ability to manage the project
• pragmatic !
• ability to communicate with the business and developers
• know the product… and thus, the trust of the business
• flexibilty
• a great personality

Please enjoy and let me know what you think.

This is an attempt to put thoughts into words. To document how I think, we as a company, should be looking at the practice of public speaking. Whether a presentation at a large conference or lightning talks over lunch with your teammates.

Before I begin, a little background on how I arrived at this opinion. At the end of 2013, I started reflecting on my contributions to the technical community. I realized that I had a great passion for speaking and communicating my ideas to my peers. I also realized I hadn’t made much of an effort to contribute back to the community. So… an effort was made to up the ante. I concentrated on presenting as often as possible during 2014. At the end of 2014, I had presented at 13 conferences. 2015 is starting off well, with two conferences booked. Hope to see many of you during the 2015 year… I will be presenting at Agile and Beyond 2015 and self.conference 2015.

Read more »

the spike… why is the spike such a complex concept for a team to understand.. grasp.. embrace? Why would anyone want to work on something for a short amount of time, gather some information, answer a question and then throw your work away… just to do it again for real. spikes allow you to make better decisions and possibly determine if something is feasible at all… all without wasting a huge amount of time and/or money.

so… when do you actually perform a spike? when is it the right time to not deliver real value to the business? well, when you think of it that way… the answer should be never. although, ‘never’ is not really a viable option… when the known is not known… the spike is the way for the team… to do a little digging into the unknown and then, create a viable solution with more information in your pocket. spikes are not just confined to technical decisions… spikes should be used any time the team is unsure of what is the next step… hopefully allowing the team to answer the question with definitive assurance. Please spike… it will make the business very uncomfortable at first, but with honesty and practice, the business will see the real value of why spikes should exist.

as you might expect… spikes are a lot of things, but they are NOT: 

• NOT a way to slip untested code into the production stream
• NOT a way to allow the team to make uneducated guesses at estimating stories and then cleaning up the guess with a spike
• NOT a way for improperly defined (missing definition of ready criteria) user stories to enter the groomed backlog

ok… here is where I lose most people.

spikes should be treated the same as all user stories on the card wall. spikes should be evaluated for the possible business value each will help define. They should also be estimated… estimated because each spike will reduce the capacity of the team. Many teams do not count spikes towards their velocity… I personally do not agree with this. This appears to me to be a lie to the business. (We can also compare this with defects, but that is another topic). The process of determining velocity is not an effort to collect points or apples or whatever, but a process of allowing the business to have a means to determine how much of something they can get within a certain amount of time. The concept of ‘getting credit’ should be considered something the team should not engage. velocity is not about gamification of the agile process. Report the actual velocity based on the actual work of the team… who cares whether you call them… user stories, defects, technical debt or spikes. work is work… and thus reduces the amount of capacity a team has promised the business.

In order to make spikes a little easier to digest… spikes should not be allowed to consume huge portions of the sprint. time-box them using a small estimate. you know your system… pick a reasonable estimate… it is probably not your smallest card on the wall, but definitely not the biggest either. If a spike is estimated and the team working the spike feels they have reached the end of the estimation period… then the spike is done! period… end of story. If the spike is still unable to answer the question, it is possible another spike will need to follow. this is a business decision… it is up to the business to determine if yet another spike should be played. it is not a bad thing to play more than a single spike to answer a question, but each cycle should be carefully evaluated and the business should inevitably by the deciding factor. If the spike is of a technical nature, it is the responsibility of the technical staff to sell the business value to the business, but the business will make the final decision.

spikes will not always result in additional user stories being created. many times, a spike will be initiated by the process of estimating an existing user story. the user story doesn’t have enough detail or the technical questions will not allow the user story to be estimated with certainty… a spike will be required to answer these questions. At the end of the spike, additional cards may or may not be required… simply filling in the knowledge gaps will allow the existing user story to be estimated. On the other hand, a spike may actually result in additional user stories being created.

so… just how does a spike fail… well… I actually think it is very difficult for a spike to fail. spikes are designed to answer a question, fill in the gaps, allow for more informed decision to occur. any information you gather during the spiking process will result in a better position to answer these questions… so, therefore, you are more informed and better off. the only way to truly fail would be a spike that answers nothing, gathers no information and wastes a portion of the teams capacity.

the results

what do you do with the information you have gathered during the spiking process? As far as the code you have written… learn from it and then throw it away. This is just spike code, without tests, this code should never be considered good enough to be production code. Do NOT allow yourself or anyone else to be swayed to use the code. it will come back to bite you… just do not do it. DELETE the code ! this also does not include putting the code in a special branch within your code repository for later retrieval… DELETE the code !!! As far as the result of the spike, document your findings, positive or negative… this will help with the decisions based on the result of the spike. A lot of times, at the end of the spike, the team will make a decision and then forget to share the findings with the team… the team playing the spike may not be the same team that plays the subsequent cards associated with the spike.

spikes are not magical. they are special in their purpose, but they do not bring magical results to the project other than they are a great way to reduce a risk and allow future cards to proceed across the wall more consistently. spikes are a great way to engage the business and allow for quicker more thorough feedback and a better understanding of upcoming complexity. complexity that will surely derail the sprint/iteration if left uncontrolled.

when to use

when should you utilize a spike… at least a couple ideas to get things started:

• the team is in a position where they do not understand something… could be the business context of the problem or a new technology unfamiliar to the team.
• a story is just too big to get a grasp on… and without breaking the problem down… you will not be able to effectively estimate.
• a new technology has been introduced and the risk of the new technology is adding significant risk to the successful estimation and probable delivery of the story.

good luck with the process of spiking.

So… now that I have suggested throwing your card wall away, maybe I should spend some time trying to explain and inevitably convincing you otherwise. Please keep in your mind… many teams are successfully delivering software… and they continually have issues with the purpose of the card wall and its mechanics.

The card wall should: - bring the team together - give the team a place to congregate and discuss the status of the project, which is inevitably the status of the team. - improve the communication of the team. This improved communication aids in the removal of blocks and decision-making.

A well-executed card wall will provide the following: - what is the current commitment of the team - what is the team working on, both… at a team level as well as at the individual - who is working on what… are they working on too many cards… are they working at all. - what are the current blocks… and the status of the block - a snapshot of the teamwork. - a visible workflow - WIP (Work In Progress) limits used by the team… are they violating them? - a backdrop for the stand-up

Why is card wall management so difficult?

Because it is not easy. Well, that seems like a dumb answer, but an answer non-the-less. The management of the card is inherently difficult because there are so many moving parts. Any good card wall will have the complete status of the team at any given point in time. For instance:

• the number of cards in the backlog.
• how many of these cards have estimates… hello ! they should all have estimates… cards should not be in the groomed backlog unless they meet the definition of done… which includes a proper estimate.
• how many of these cards are blocked… and by this I mean, truly blocked. Not because someone ‘special’ isn’t available to work on the card… or someone is on vacation… or they are IN A MEETING. But a real block.
• how many cards are in progress
• has the team violated their WIP limit
• is someone working on more than one card
• how many days has the card been in the ‘in progress’ column… replace ‘in progress’ with whatever columns your team has
• a small story remained in a single column for too long
• is there a bottleneck within a specific column or columns
• how many days are remaining in the sprint/iteration
• which cards have been accepted

But, why is it so difficult? We have still not answered the question. It is hard mainly because the team needs to get on board with the purpose of the practice. The card wall is not there to make your life difficult. It is there to make things big and visible, which can be painful at times. But, there to, in one spot, show all of the teams successes and challenges in the same spot, at the same time. Sometimes, people do not like for everything to be ‘out there’ where everyone can see. Stop making a big deal about what you do not want to show the world and use the board to accelerate teh team to a new level of productivity and success.

Why to teams make the card wall such a constraint?

I do not know that I have the definitive answer to that question, but I can speculate. They are scared of what information the wall will present to the outside world. If the card wall is a mess and the outside observer (whether a passer-by or your manager) attempts to read the board… the confusion will limit their ability to decipher. Please stop doing this. A well-executed board will allow the status of the team to be bigger and more visible. You are more capable of recovering from a bad situation when the rest of the team knows the issue and can react and provide assistance.

Who should own the wall?

the Business?…

the Scrum Master?…

the Technical Lead?…

the team?

In my world, the card wall is owned by the team. The business is responsible for putting cards within the backlog… in priority order. They should add/remove/rearrange as much as they like. As soon as the card is removed from backlog to the ‘in progress’ column, the business has lost the card. If the business decides a card, already in progress, needs to be postponed or cancelled… the team takes the points and gives the card back to the business. If the business decides the card needs to be placed back in to the backlog (at some point)… reestimation needs to occur. This is not to be considered a point collecting exercise, but the cost of context switching.

There are an infinite number of possible layouts, and should be determined by the team. Here is a basic layout I would start with.

Backlog

Cards that meet the ‘definition of ready’ (defined later). But in general… cards that are well defined, thought out and ready for someone to work… NOT cards that are blocked in some manner. NO Missing Acceptance Criteria !!!

In Progress

Upon entering this column… an entry conversation should occur. I will leave it up to the team to define the participants, but the entry conversation is key and should not be skipped. Many teams call this entry conversation… the ‘three amigos’ conversation… a developer (pair), a tester and a product owner… or some similar combination. After this clarifying conversation… the card can actually be considered ‘in progress’.

This column should be where all of the cards, that are currently being worked on, are located. A reasonable WIP should be defined and all cards currently ‘in progress’ by the team should be in this column. This means everything (every user story). If a team member is working on ‘something’… that ‘something’ needs to be put on a card and placed in the ‘in progress’ column. When a team works on tasks outside the scope of the team space and are not managed on the wall… therse are generally the teams that never meet their commitments or the team that is continually finding themselves in the middle of a death march.

Ready To Test

Development has completed the user story… test driven of course… and verified all of the acceptance criteria are met. This might (should) include sitting with a tester and verifying the user story is delivered as requested. The user story is now ready to be picked up by the testing team and verified… not on a developers machine, but the testing environment… the environment the application is automagically pushed to by the continuous integration process.

Let’s work from left to right.

Some Key Concepts Associated with the Card Wall

definition of ready

this is a tough one. The definition of ready should be ‘what’ the team agrees upon as a litmus to determine if a user story is ready to be worked by the team. A user story should not (and in my world, can not) be added to the groomed backlog until all of the terms of the ‘definition of ready’ have been met. Skipping, or worse… ignoring the DOR can cause lots of problems. Here are a couple examples of what might be contained on the DOR…

• all acceptance criteria defined
• story sized
• all external dependencies identified
• clear description of business value
• etc.

dots on cards

This is a personal one. I like each team to put small indicators on each card at the completion of standup each morning (or whenever you have daily standup). Each column on the card wall is assigned a different color indicator… including a way to mark the occurence of stand up and if a card is blocked at the end of standup. For example… if a card is moved from ‘backlog’ to ‘in progress’… at the completion of the next standup… a ‘red’ dot would be placed on the card (if the card was still in the ‘in progress’ column). Each column is treated the same, but with it’s individual color. These dots allow for the daily analysis of which cards are stalled and which cards need assistance. All of the cards should be analyzed in order to determine patterns over time.

names on cards

This one seems pretty straight forward to me. Each card on the wall should have a pair of names (you are pairing… right?). The names are a great way to know who to ask when you have a question about a card. It also helps to know when someone needs something to work on. Also… it helps to know when someone is violating the teams WIP limits. Please put names on the cards.

blocked cards

excursus

put the excursus definition here

This one is mine… I invented it. The ‘EXCURSUS’… a divergence from the main point of topic… or in my mind… ‘things’ you want to talk about after the standup is complete. These can be…

• information about an upcoming meeting
• a ‘teachable’ moment
• reminder about an upcoming holiday
• a tech moment

swim lanes (WIP)

If you find yourself in a team space where the team is unable to manage their work in progress… introduce a swim lane. If a column on the card wall has been limited to a certain WIP limit… divide the column into the same number of sections and only allow each section to have a single user story at a time. The team will first push back, but it will be very visible when the WIP limit is being violated.

days remaining

Pretty simple… the number of days remaining in the sprint. It is nice to be able to look at the board quickly and see how many workable days remain.

expected / accepted

Another pretty simple one, but powerful information. Expected number of points to be completed by the end of the sprint… and the number completed. This one really works with the ‘days remaining’.

business backlog (ungroomed)

talk to the wall

Each pair on the team should speak to the cards on the wall. This forces each pair to only work on ‘things’ that are being managed by the wall. It also allows the rest of the team to remain focused on which column the cards is currently contained and if the pair needs immediate assistance to complete the card.

Let’s talk to wall from right to left and bottom to top.

drag cards

Cards should be added to the card wall… when someone on the team is pulled from the team space to work on something else. Any work, completed by the team, not directly associated with the team (production support, helping another team, etc.) should be put on the wall (hours are fine). These cards will allow for the proper analysis (at the end of the sprint)… especially when the team commitment is not met.