tag:blogger.com,1999:blog-89900291121051821102024-02-19T04:33:04.469+00:00Scrum+Building better places to worktesthttp://www.blogger.com/profile/05320199098014551969noreply@blogger.comBlogger71125tag:blogger.com,1999:blog-8990029112105182110.post-79372374809831619592013-10-15T08:33:00.001+01:002013-10-15T08:33:39.918+01:00I don't own my team<p dir=ltr>If you know me you know that I strongly believe that the language we use shapes our thoughts. I hate the dehumanizing use of resources when we mean people, or use of 'the business' when referring to people outside of IT.</p>
<p dir=ltr>The new phrase that I'm trying to eradicate from my language is 'my team'.</p>
<p dir=ltr>Since moving back into a team lead role I've started using this phrase again and it's been making me feel increasingly uncomfortable. It does so in two regards. Firstly, it's possessive as if I own the team. Secondly, it makes me feel that I'm solely responsible for the team and their output. </p>
<p dir=ltr>In conversations with other team members, I've switched the my to an our. When talking to people outside of the team, I'm starting to refer to my own team by the team name. I also noticed that have been referring to other teams by team leader name. This needs to stop too. </p>
<p dir=ltr>By using our I feel like we're all in it together rather than me being above the team or owning them. </p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-77987292465061123802013-08-05T18:32:00.001+01:002013-08-05T18:32:55.089+01:00Missing feedback loop. How can I serve a team member better?<p dir=ltr>In one-to-one meetings with my managers, past and present, I've asked about things I could do better. I've just realised that I've never asked the people I manage the same thing. How could I serve them better? </p>
<p dir=ltr>Some people might see this as weakness, but I see it as the opposite. If I'm not getting feedback other than top down, I'm missing a critical piece. </p>
<p dir=ltr>This shouldn't be an annual thing either, but a continual process of improvement both ways. </p>
<p dir=ltr>Of course this is going to require trust, which has to be built over time, but it's not going to stop me taking the first step. </p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-24474834664236916972013-08-02T08:26:00.001+01:002013-08-02T08:26:02.086+01:00The absurdity of 'the business'<p dir=ltr>I've often heard software development departments refer to other parts of the organisation as 'the business'. Not only is that wording divisive, but it's also completely absurd. I've often heard the same departments that we call 'the business', also calling other parts of the organisation 'the business'. We're all the business; we're not a lesser or greater part; we're all in it together</p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-1316077434385767902013-05-01T19:56:00.001+01:002013-05-01T20:37:47.347+01:00Software development career treadmill<p dir="ltr">In my last post I outlined many of the reasons <a href="http://scrumplus.blogspot.com/2013/04/software-developers-are-model-for.html">why software developers are a good model for career resilience</a>. It was based on the fact that we have to be resilient due to how quickly technology and trends move. </p>
<p dir="ltr">Several times in the past, I've been asked what one thing would I tell people considering a career in software development. I always give the same piece of advice; be prepared to continually learn. </p>
<p dir="ltr">There are downsides to this continual learning cycle though; I've dubbed this the software development treadmill. This treadmill keeps on going at a slightly uncomfortable pace and doesn't relent no matter how tired you get. This continuous pace requires you to have a passion for software development. Without that passion, it's been my experience, you'll washout or stagnate into a career deadend. Passion is critical because it will help keep you motivated to continually learn and practice, most often in your spare time. </p>
<p dir="ltr">Even those who do continually learn and practice aren't guaranteed to always be on top of new technology and trends. This is mainly because there are so many things that you could spend your time on. You end up having to pick and choose based on what interests you and your guess at where the industry is going. Sometimes you'll hitch your cart to the wrong horse and will have to leave that deadend; then scramble to catch up with what the market is actually doing. </p>
<p dir="ltr">For developers in the west, there's also the constant fear of being outsourced. This adds an extra pressure to keep up.</p>
<p dir="ltr">Eventually even lifelong learners can get tired of this unrelenting pace of change. Traditionally developers would move up into management, where their development skills don't have to be as sharp. That said, I've noticed that with the advent of self-organising teams and flatter hierarchies, there's less of a need for management and therefore less opportunities for promotion; these positions were limited before anyway. As a result we're staying in development jobs for a lot longer. This presents additional challenges. As you get older your family commitments generally increase. This means that you have less time to learn and practice on your own time.</p>
<p dir="ltr">Finally there's an unspoken darkside of being an older developer and that's that it's seen as a young person's game. There's a myth in the industry that young people are far more creative. If you want to have a long career in software development you'll need to be on top of your game. </p>
<p dir="ltr">Has this been your experience as a software developer? I'd love to know either way. </p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-40131851626964444812013-04-22T20:06:00.000+01:002013-05-01T20:19:05.671+01:00Software developers are a model for career resilience<div dir="ltr">
Since the official end of the Great Recession, the private sector has pretty much rebounded. The Dow Jones has recently hit all-time highs and some companies are now posting record profits. Despite this, unemployment has remained stubbornly high. <a href="http://economy.money.cnn.com/2013/04/09/job-openings-unemployed/" target="_blank">In the US there are three unemployed people for every job opening</a>. We've also seen old business models are being disrupted and companies that can't adapt are closing their doors.</div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
With this in mind, people are now having to become more creative and adaptable with their careers. You can no longer rely on a company to help you design a career path. It's up to you now. </div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
In a recent conversation it struck me that software developers are naturally career resilient and, in my opinion, serve as a good model for others. </div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
So why are we more resilient? Because we have to be.<br />
<br /></div>
<div dir="ltr">
Our field is always in a state of flux. Programming languages, frameworks and technologies go in and out of fashion. It's very easy to get caught out by focusing on one language and suddenly finding that the industry has moved on; leaving you behind. This is hard to come back from. If you don't continually keep on top of new technologies and learn new skills, you'll stagnate and be stuck. <br />
<br /></div>
<div dir="ltr">
Another reason you can get stuck is due to skill related pay. When you have a skill that's in demand you get paid a premium for that. When the market moves and you don't, you can struggle finding a new job that pays as much as the previous because that skill is no longer in demand. This might not be completely obvious until you try to make a move. <br />
<br /></div>
<div dir="ltr">
Another wrinkle is that technology choice can be geographical. For example, working in London in the late nineties - early 2000s most web application shops used Perl. When I moved to Houston there were very few companies that were looking for Perl developers. I ended up finding a job at one of the few Perl shops in Houston, but the local industry moved to .NET so I did the same.<br />
<br /></div>
<div dir="ltr">
Software development contractors are even more resilient than their fulltime counterparts.They are able to shift from position to position; only looking for the next position a week or so before the current one ends. <br />
<br /></div>
<div dir="ltr">
How resilient is your career? <br />
<br /></div>
<div dir="ltr">
For more information about increasing your career resilience, I recommend reading the following article by Michele Martin:<br />
<br />
<a href="http://www.michelemmartin.com/thebambooprojectblog/2013/03/the-four-patterns-that-should-guide-all-your-career-moves.html" target="_blank">Career Resilience: The Four Patterns that Should Guide All Your Career Moves</a><br />
<br /></div>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-51185023936205766102013-02-22T17:34:00.001+00:002013-02-22T20:52:48.545+00:00Let's break our dependence on being told what to do<p dir=ltr>The 20th century model of work was one of hierarchy, one where your superiors you told you what to do. </p>
<p dir=ltr>Many people are still stuck in this mindset. It's easy to do. When you're not being told what to do you feel uncomfortable and unsure what to do. I've fallen into this at times in the past too. </p>
<p dir=ltr>The problem is, if you are dependant on being told what to do, you become less creative, adaptable and resilient. If you find yourself in an uncertain situation, you're more likely to fall back on things you've done in the past rather than looking for something new. </p>
<p dir=ltr>Right now, the future of work is uncertain. We're currently going through a time of rapid technological innovation. Organisations are able to do more with less people. Companies that don't innovate are going out of business as new ones disrupt legacy business models. This amongst other things, is causing unemployment to rise. Hundreds of people are competing for a handful of jobs. </p>
<p dir=ltr>As existing jobs are automated we're going to need to find new problems to solve, which means people to be able to think for themselves. </p>
<p dir=ltr>I believe that we should create organisations that have a culture of innovation, where all employees can use their own creativity and ingenuity to solve problems. Not only will this help companies become more adaptable and resilient, but by doing this we can help people break the dependency on being told what to do. This in turn, will help them find their own ideas to tackle and ways to thrive in this uncertain future. </p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com1tag:blogger.com,1999:blog-8990029112105182110.post-28185635197814128922013-02-20T19:30:00.002+00:002013-02-21T12:51:19.406+00:00Say no to degree discrimination<div dir="ltr">
I'm going to come straight out and say it. If you're hiring for a position that doesn't require a degree, yet you're requiring one, you're discriminating plain and simple. Plus you could be missing out on a potentially good candidate.<br />
<br /></div>
<div dir="ltr">
I'm frustrated after reading an article from the New York Times about the <a href="http://www.nytimes.com/2013/02/20/business/college-degree-required-by-increasing-number-of-companies.html">increasing number of companies in the US requiring a batchelors degree</a> for all open positions. This growing trend really concerns me because it's an artificial barrier that not everyone can get over.<br />
<br /></div>
<div dir="ltr">
Hold on James, are you worried about this because you don't have a degree? Damn Skippy I am, but there are plenty others out there too that don't deserve to be discriminated against.<br />
<br />
So here's one of the reasons I'm frustrated. Within the first few paragraphs of the article I came across this quote:</div>
<div dir="ltr">
</div>
<blockquote class="tr_bq">
"College graduates are just more career-oriented," said Adam Slipakoff, the firm's managing partner. "Going to college means they are making a real commitment to their futures. They're not just looking for a paycheck."</blockquote>
This is a gross generalisation if I've ever heard one. A degree doesn't mean anyone is more career orientated (or is better learner, but that's a subject for another post). Perhaps they can't afford to go to university, which is an increasing problem as costs rise. Perhaps university isn't the best place for them to learn. Perhaps they're just tired the education mill by the time they graduate from high school.<br />
<br />
What happened to the people without degrees that started in the mailroom and worked their way up to CEO? Isn't that part of the American dream? Are these people not career oriented?<br />
Hint: they're still out there.<br />
<br />
I've met plenty of people with degrees that haven't a clue what type of career they want, and I've met plenty of people without degrees that are very career focused. In fact some of the most talented software developers I know don't have a degree. One thing that they do have is a love of learning.<br />
<div dir="ltr">
<br />
As I mentioned I don't hold a degree myself, yet I've had a sucessful career as a software developer and software development manager. When I started my career as a software developer, I actually had to unlearn what I was taught in formal education on that topic. For me, university just wasn't the right learning environment for me. I learn best by doing. </div>
<div dir="ltr">
<br /></div>
<div dir="ltr">
If someone has a passion, they don't have to have a degree they will learn what they need as they go along.<br />
<br />
Obviously there are some careers that definitely require higher education, but a lot can be taught on the job.<br />
<br />
This brings me to my next point. A few paragraphs later I came to this quote:<br />
<blockquote class="tr_bq">
"When you ge<span style="font-family: inherit;">t 800 <span style="background-color: white; line-height: 26px; text-align: left;">résumés</span> for every job ad, you need to weed them out somehow," said Suzanne Manzagol, executive recru</span>iter at Cardinal Recruiting Group</blockquote>
If you're filtering on something that's irrelevant to the job, why stop there. Are you going to filter on gender, age or race? No because there are laws preventing that. What would you do if the government said you couldn't filter needlessly? When I hire, I put my money where my mouth is. I don't discriminate on any of the above.<br />
<br />
Degrees also become even more irrelevant as a person progresses through their career. What if you have a candidate that has far more experience, but no degree?<br />
<br /></div>
<div dir="ltr">
I have an idea. Let's filter out candidates on something important, whether or not they can do the job and whether they have a passion for learning. If you have too many people applying for a position, that's s good thing. <br />
<br />
I think I've made my point. I'll leave you with some rampant elitism:<br />
<blockquote class="tr_bq">
<span style="background-color: white; font-family: inherit; line-height: 26px; text-align: left;">"Besides the promotional pipelines it creates, setting a floor of college attainment also creates more office camaraderie, said Mr. Slipakoff, who handles most of the firm’s hiring and is especially partial to his fellow University of Florida graduates. There is a lot of trash-talking of each other’s college football teams"</span></blockquote>
</div>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com2tag:blogger.com,1999:blog-8990029112105182110.post-55859890842330684512013-01-15T19:17:00.001+00:002013-01-15T19:17:47.317+00:00Unbalanced self-organising teams<p dir=ltr>In my experience it's very easy to disrupt the balance of a self-organising team, just change someone's status within the company. If a self-organising team is made up of peers, each person takes leadership dynamically. Even if the team has a few junior members they tend to fall into a mentee - mentor dynamic. If one person is perceived to be more important the team will look to that person for leadership. I'm not saying that self-organisation can't work with an imbalance in status, it's just that different considerations are needed. </p>
<p dir=ltr>Firstly it's up to the person in question to understand this change in dynamic and address it directly with the team. One idea is for the leader and team to come to an agreement that no one person is more important than the others. Put this agreement on the wall in the team's working area. That way they can point to it and hold the person with more perceived importance to it if necessary. </p>
<p dir=ltr>Note: Violation of that agreement, can send a message to the other team members that the leader doesn't agree with the working agreement.</p>
<p dir=ltr>What are your experiences with unbalanced self-organising teams?</p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-25511600191290378262013-01-07T15:02:00.002+00:002013-01-07T15:02:10.273+00:00Downtime and employee focus<span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">In all places of work, there will be periods where people will have downtime. Conventional wisdom states that "idle hands are the devil's playthings". This might well be true if someone cannot channel their energies in an appropriate direction. To get around this problem many organisations try to optimize on efficiency to achieve the mythical 100% utilization. That way no-one will have downtime and be unconstructive, right? </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">This might be possible for machines, but not people. We don't operate the same one day to the next and you can't predict how someone will be feeling on a specific day. Perhaps they didn't get enough sleep; perhaps they're having problems at home. In addition, organisational slack helps businesses adapt better when their market shifts and more.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Coming back to downtime, clearly a company doesn't want people sitting around doing nothing. I can understand that. If an organisation lives their values and has worked hard to engage the employee in their work, then that opens up the possibility of the employee using that downtime for the benefit of the company. The problem comes when the employee isn't engaged with their work.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Let's focus more on engaging employees rather than trying to keep them busy.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Do you agree or disagree?</span>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-76445095740345614082012-12-10T19:40:00.001+00:002012-12-10T19:40:21.996+00:00Sharing bad news<p dir="ltr">If you have to give someone bad news, do it straight away. Don't draw out the conversation. Your body language will give the recipient hints that bad news is coming. The longer the lead up the more stressed they'll become and more likely they'll react badly. </p>
testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-8683366673854531222012-10-29T19:37:00.001+00:002012-10-29T19:37:30.726+00:00Team visions<div><p dir=ltr>A vision is an often missing piece from software development teams. It is a powerful technique because it allows them to envision where they ultimately want to go. This allows for focus and then they can then take small steps to get there. </p>
<p dir=ltr>I've found that teams rarely know where they want to go other than a loose self organising team or high performing team. Not having a vision can stop them from making effective improvements in how they work. Small changes are made but can be scatter shot. Eventually they may become an effective self organising team, but not as quickly as they could have. </p>
<p dir=ltr>So if you don't have a vision create one in your next retrospective. It can be a lot of fun discussing what you want your team to be like in an ideal state. Just remember though, the vision should be revisited occasionally because it can change over time. </p>
<p dir=ltr>Does your team have a vision?</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-49882395408985819082012-10-18T08:33:00.001+01:002012-10-18T08:33:44.529+01:00Team values and changes in membership<div><p>Following on from my post yesterday about changing team membership and working agreements, today I'm going to talk about values. </p>
<p>Most of the values a team holds are learn through osmosis. As the team works more and more together they generate a shared mental model of how the team works and interacts.</p>
<p>So what happens when team membership changes? The team's values might well be invalidated. Perhaps a new team member doesn't agree with the current values, but if the values aren't made explicit how would anyone know?</p>
<p>Getting these values out of the teams heads and talking about them is a valuable exercise. Not only does it allow the team to understand what values they each hold, but also the ones they have in common. The conversation is the most important part of this. After which they can document and display the values. This also has the added benefit of showing the surrounding company what you value and may spur more conversation. </p>
<p>Back to our new team member. He or she might value the same things. In that case, great. If they don't agree then there's a conversation that needs to be had. The team might still agree to keep the same values, but with buy in from the new member. They might also agree to change them. </p>
<p>The important things are the conversation and the buy in from all team members. Without the buy in it's hard for someone to really live those values. </p>
<p>Finally compare your values to that of the surrounding organization. Is there a match or mismatch? This may generate more conversation at a higher level. </p>
<p>Have you made your team values explicit? What do you value?<br>
</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-83335643664847879532012-10-17T17:31:00.001+01:002012-10-17T17:32:35.043+01:00Working agreements and changes in team membership<div><p>Teams have both implicit and explicit working agreements. The ones the team does without thinking, and the ones that they've agreed on and written up. Explicit agreements can become implicit over time as the team internalizes those agreements.</p>
<p>What makes us think that adding or removing people from that dynamic won't affect the team?</p>
<p>Whether they are implicit or explicit, working agreements can be invalidated if the new team membership don't all agree. The entire team is meant to agree and not impose their rules on the new membership. The team has to find it's own path again. </p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-39127281577624519382012-10-07T19:52:00.001+01:002012-10-07T19:52:33.232+01:00Don't forget to iterate!<div><p dir=ltr>In the 1964 case Jacobellis v. Ohio, Justice Potter Stewart wrote that hard core pornography was hard to define, but that he'd know it when see saw it. </p>
<p dir=ltr>This also applies to product development. It's hard to define what you want, as people have a hard time envisioning the future. When someone actually has something tangible they can make better decisions about what they want. i.e. they know what they want when they see it. </p>
<p dir=ltr>One of the reasons why agile software development works is by shortening the feedback loop and adjusting a project based on the things that have been learnt over it's lifetime. This can be done in a couple of ways. Firstly by doing incremental development and secondly by doing iterative development. Unfortunately many Scrum teams focus on the former and forget about the latter. Incremental development it easy to understand and is baked into the Scrum cycle. It's expected that at the end of a sprint that we have a 'potentially shipable product increment'. I believe that this wording is partially responsible for creating a misunderstanding that we should only be incrementing. </p>
<p dir=ltr>One anti-pattern I've seen is when a team tries to develop an entire feature in a story so that they have their potentially shipable product increment. This feature is complete as far as they're concerned so they can then proceed to the next story and do the same. These stories then only get reviewed by the Product Owner (PO) in the sprint review meeting. Though there's a much shortened feedback loop compared with traditional software development projects, we've lost some of the learning. We shouldn't just learning about what features need to be developed, we should also be learning about how a feature is developed. This is where iterative development comes in. We need to getting something into the hands of the PO as quickly as possible so that they can see if it's really what they want. </p>
<p dir=ltr>I recommend doing the following:</p>
<p dir=ltr>1) Treat each feature like an experiment. Build a hypothesis about what you're trying to achieve then go about proving or disproving it. </p>
<p dir=ltr>2) Slice your feature into stories as thinly as possible. Start with the simplest possible implementation of the feature. Put things such as safety or experience factors into subsequent stories. </p>
<p dir=ltr>3) Shorten the feedback cycle. Talk to your PO throughout the sprint. Show them as the feature evolves and gather feedback. Some of this feedback will generate more stories. Others will allow us to make smaller course corrections. We're continually learning.  Also remember that your PO is meant to be a partner in this effort, a collaborator. </p>
<p dir=ltr>4) Deploy each completed story into a staging environment so that the PO or trusted end users can start playing with it. Remember that just because a story is of a potentially shipable quality, it doesn't mean it can be shipped. That decision is up to the PO.</p>
<p dir=ltr>To sum it all up, don't forget to iterate!<br>
</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-14436387490380100342012-09-27T18:22:00.001+01:002012-09-27T18:22:01.566+01:00Agile Cambridge session: Questions not Stories: Build a business-value oriented team<div><p dir=ltr>The last session I attended today was run by Adrian Howard. Going into <u>it</u> I thought that the session was going to be about replacing user stories, but this wasn't entirely the case. Essentially it was about starting with a user story and then conducting an experiment. </p>
<p dir=ltr>Adrian used the following example:</p>
<p dir=ltr>As a potential customer I want to be able to signup with my Twitter account so that I don't have to fill out a registration form. </p>
<p dir=ltr>The first step is to turn the story into a question. </p>
<p dir=ltr>As a potential customer I want to be able to sign up with my Twitter account so that I don't have to fill out a registration form?</p>
<p dir=ltr>The next step is to ask why the story is needed. Too many times we just assume that there are good reasons for it and don't question. After finding out the main reason why, we should design a hypothesis to validate that assumption and then conduct an experiment to prove or disprove it. </p>
<p dir=ltr>Adrian's team wanted to validate that a percentage of new users would want to signup using twitter. </p>
<p dir=ltr>To do this they put a fake Twitter link page which logged how many people clicked on it. The user was then redirected to a page saying that the Twitter signup was currently offline and redirected them to the normal registration page. </p>
<p dir=ltr>After the experiment was over they found that very few people actually clicked on the link, so they didn't build the feature. Traditionally the team would have just built it and no one would validate if it was ever used after being deployed. </p>
<p dir=ltr>This has potential to be a catalyst for turning an organization into one of experimentation. </p>
<p dir=ltr>I'm still mulling this over, but I think it has great potential. </p>
<p dir=ltr>What do you think?<br>
</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-88241275740268216862012-09-26T08:00:00.001+01:002012-09-26T08:03:57.894+01:00Sleep, creativity and culture<div><p dir=ltr>Note: The following is a brain dump of what I currently understand and what I'm trying to understand.</p>
<p dir=ltr>I've been thinking a lot about time recently and how we're dominated by the clock. It controls every aspect of our lives, even during sleep. The following are my thoughts based on information that I've read and my own life experiences.</p>
<p dir=ltr>Due to the pressure of modern life, most of us function with less than the recommended eight hours. This is mainly because of our culture. The dominant work culture frowns on sleep, especially around the topic of entrepreneurship and leadership. Sleep is for the weak. There's time for sleep when you're dead. These are just some of the phrases that are indicative of that culture. There's an increasing amount of information about why we should get more sleep and we know that we should but we don't.</p>
<p dir=ltr>Sleep is extremely important for our overall health and especially for our brains. During sleep the brain basically reorganizes itself, choosing which connections to make and what to discard. Sleep also improves our creativity. It's also been shown that one of the times we're most creative is when we're sleepy. This is because you tend to make more connections between disparate thoughts at this time. To harness this creativity it's recommended that we ease into our day, not rush out the door. For example, I spend the first 15 minutes after I wake up just mulling over what ever comes to mind. I also take a leisurely walk to the station each morning in which I do the same thing. Those times are when I tend to have some of my most creative thoughts and I'm not a morning person.</p>
<p dir=ltr>Perhaps our sleep cycle is a result of our modern lifestyles. I've been reading a few articles recently which have found that eight hours of straight sleep isn't necessarily our natural sleep cycle. It appears that information is coming to light that historically humans would sleep in two parts. We would enter what has been called first sleep, or little sleep, wake up for a few hours and then enter a second deeper sleep. The single eight hour sleep cycle appears to have been a relatively recent occurrence in the grand scheme of things. This might account for people who often wake up in the middle of the night for several hours. Unfortunately because we are dominated by the clock this time awake. It also matches the sleep cycle of some children with autism. My son for instance will wake for several hours a few nights a week. He'll generally be content to quietly play or talk to himself for a few hours (though that wasn't always the case), before returning to sleep.</p>
<p dir=ltr>Waking up in the middle of the night can cause undue stress for some. We worry about not having enough sleep for work the next day which decreases the likelihood of getting back to sleep. This worry is caused by the the work culture I mentioned above and our lives being dominated by the clock.</p>
<p dir=ltr>So why do we stress about when we get into work? This is something I've never really understood for knowledge workers. If you have a meeting then it's a sign of respect to the other participants that you be there on time. Being late sends an implicit message that your time is more important than other peoples. Getting into work at some arbitrary time which doesn't seem to add any value and causes stress. If I've had a bad night sleep isn't it better for the company that I get in later so that I can perform better? Being exhausted at work does no one any good. We're all adults and should be trusted to put in the hours the company requires of us without having to stress when you're arriving or leaving. How many times have you sat at work at the end of the day, but you're too tired to do anything, especially late in the week? What happens is that people make themselves look busy. Wouldn't it be better for that person just to head home early and recharge?</p>
<p dir=ltr>Another idea is for companies to let people nap during the day. Several studies have shown that taking a nap, where you achieve a deep sleep, improves creativity.</p>
<p dir=ltr>All of the above mainly applies to people in creative jobs. We tend to need large blocks of time to concentrate and achieve flow. This is different from managers who generally work in smaller hour blocks. Getting these large blocks of time might require being on a different schedule from managers. For example, working late in the evening because there are less distractions.</p>
<p dir=ltr>We need to change our work culture and habits to help improve the creativity of knowledge workers rather than ruling by the clock.</p>
<p dir=ltr>What do you think?</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-2644952218022341002012-09-21T08:45:00.002+01:002012-09-21T08:56:03.266+01:00Do not fear your Product OwnerThe role of Product Owner (PO) is an essential one, but is also one that teams often fear. I've felt that fear myself in some environments.<br />
<br />
Perhaps they are higher up in the org chart, but what does that matter?<br />
<br />
Your PO is not your parent and you shouldn't assume a parent/child relationship. They are your team member in producing high quality software. Sure they might have different responsibilities, but you're all professionals and experts in your own domains. Treat each other as such.<br />
<br />
<ul>
<li>Don't be afraid to ask them questions. </li>
<li>Don't be afraid of making mistakes or taking risks</li>
<li>Don't be afraid of challenging them. </li>
<li>Don't be afraid of telling them when they aren't doing what they need to be doing to help the team. </li>
<li>Don't be afraid to tell them if their actions are detrimental to the team.</li>
</ul>
<div>
Try not to be afraid. If you are, recognise it and then push through. Work together as professionals.</div>
<br />testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-91608147415164436112012-09-09T21:39:00.001+01:002012-09-09T21:41:36.227+01:00What do Kung fu and ScrumMasters have in common?<div><p dir=ltr>I look at being a ScrumMaster a bit like Caine from Kung fu, but without so much ass kicking.</p>
<p dir=ltr>Instead of going from town to town we go from team to team. We teach them, coach them, guide them and leave them when we're no longer needed. </p>
<p dir=ltr>This isn't the type of ScrumMastering that you're going to learn from a woefully inadequate 2 - 3 day certification course. This is what you're going to learn from practice, self improvement and others experienced in the field. That said, even if you're new to this, it's important to understand where your journey is going to lead you. </p>
<p dir=ltr>Firstly though we need to look at the primary roles of a ScrumMaster a little differently. </p>
<p dir=ltr>These are the ones I perform. </p>
<p dir=ltr>1) Guide the team towards self-organization. <br>
2) Continually challenge the status quo and help the organization improve. <br>
3) Help other ScrumMasters improve their practice. </p>
<p dir=ltr>Ultimately a self-organizing team will no longer need you. That's when you can walk away, head held high and say "My work here is done". </p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com1tag:blogger.com,1999:blog-8990029112105182110.post-13444824800683185032012-08-21T07:37:00.001+01:002012-08-25T19:25:34.554+01:00ScrumMasters and impediments<div><p dir=ltr>One of the roles of the ScrumMaster is to help the team resolve impediments. i.e. things that are stopping the team or a team member from making forward progress with their story or stories. The keyword above is help. Do not necessarily do it for them. If a team member can resolve an issue, let them. Sure a SM can help have the difficult conversation or chase some hardware that's required, but we should understand why they can't resolve it by themselves. Perhaps they shy away from conflict and they are to scared to have the difficult conversation. Perhaps the hardware requisition is distracting them from coding. After understanding why the impediment cannot be resolved by the team, work with them to resolve it together. Build up their confidence to do so. The SM is the teams coach and should be helping them self-organize. By resolving all impediments you're increasing the teams reliance on you and decreasing their ability to self-organize.</p>
<p dir=ltr>How do you see the role of the ScrumMaster for removing impediments?</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-578480509290300802012-07-11T18:12:00.001+01:002012-07-12T07:56:24.010+01:00This is who I am<div><p>I am:<br>
Not content with business as usual<br>
Continually improving<br>
Building my own opportunities<br>
Following the value not my career ambition<br>
Following my passion<br>
Continually learning<br>
Dedicated to my family<br>
Doing what I think is right<br>
Working across white space not in silos<br>
Doing what needs to be done<br>
Not asking permission but asking for forgiveness<br>
Working regular hours</p>
<p>Some of the things I need to improve at.</p>
<p>All of the above and...</p>
<p>Handling conflict<br>
Obsoleting myself<br>
Standing up for myself<br>
Listening to others<br>
Putting myself in other people's shoes<br>
Helping others<br>
Taking care of myself</p>
<p>and much much more.</p>
<p>Who are you?</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-55780659643668243982012-06-19T07:46:00.001+01:002012-06-20T17:41:55.998+01:00A message to my fellow developers: I want my apostrophe back<div><p>On the web my last name is a blessing and a curse. The name itself isn't the problem, it's just how it's mutilated in the name of security</p>
<p>More often than not, when entering my last name into a web form, I receive a message that it's not valid because of the apostrophe.</p>
<p>It is a valid name, it's mine. It's O'Sullivan not OSullivan and I'm rather attached to it. </p>
<p>This isn't just limited to apostrophes, but certain other characters too. For example, a friend of mine has a space in his last name and experiences similar problems. </p>
<p>Yes I know that we should sanitize input to help prevent things like SQL injection attacks and cross-site scripting, but the former can be handled by not generating SQL with data baked right in. We can use placeholders or a full blown ORM to help prevent attacks. The latter with encoding data correctly. </p>
<p>You may think what's the big deal, but can you guarantee that you have all combinations of possible characters for last name validation? A simple a to z match isn't going to cut it.</p>
<p>One of the blessings about having an apostrophe in my name is that I learnt how to deal with them safely very early in my career.</p>
<p>Things have improved over the years though. My name used to break many an app, these days very few. If I do find one, this tells me that I shouldn't use their service. </p>
<p>My biggest problem with all this is usability. Earlier I mentioned telling the user that their name is invalid, but the bigger problem is with credit card processing. </p>
<p>Pretty much every site I've visited that asks for credit card info, asks for your name as it's written on the card. If you can't enter it exactly then it puts doubt in the mind of the user as to whether or not their transaction will succeed. There must be a reason why it has to be exact right?</p>
<p>So please can I have my apostrophe back.  </p>
<p>Who's with me?</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-91686519883445470222012-06-13T08:50:00.001+01:002012-06-13T16:14:55.444+01:00Pet peeve of the day: the business<div><p>It really makes me cringe when people in IT or software development refer to those outside of those departments as 'the business'. It night seem innocuous, but there are certain things that this simple phrase implies.</p>
<p>1) IT and software development aren't part of the business, where the real work gets done.</p>
<p>2) it creates an us versus them culture. </p>
<p>3) if you refer to yourself as separate from the business, people will treat you that way. </p>
<p>It's amazing how a simple phrase can pack in so many meanings. Just remember that we are <b>all</b> part of the business. </p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-7728543767130857092012-06-07T13:30:00.001+01:002012-06-07T13:33:09.521+01:00Retrospective safety, we've got it backwards<div>
When we talk about sprint retrospectives we talk about them as a safe place for team members to discuss their issues. This safety is normally from people external to the team, often management. This isn't what it's about, it's about having a safe environment to express your own personal views without fear no matter who is in the room.<br />
<br />
Let's start with the normal suggested practice of safety from management. This is an anti-pattern. If your teams feel that they can't be open and honest then there's something seriously wrong and that needs to be worked on. Transparency and honesty are hallmarks of agile. Your agile coach, ScrumMaster or agile manager should protect the team from outside interference. If teams don't feel that they are protected from repercussions they won't be open and honest.<br />
<br />
My previous company had two important values; say the hard things and hear the hard things. This went a long way to helping build a culture where honesty was tantamount. Did it happen all the time? No, but changing culture can take time. <br />
<br />
It's all comes down to personal safety. That doesn't mean being closed off and hiding your feelings. Quite the opposite, you should feel safe to share without repercussions. This can be especially important for team members who find it hard to discuss what's on their mind. This can be caused by a number of things. Confidence/self-doubt, fear of conflict, bad experiences, having one or more dominant people on the team amongst other things. <br />
<br />
Setting up a place where being open and honest is required, helps create a safe environment for all team members to open up. It's not quite that easy though. You *need* have a dedicated facilitator who is neutral and impartial. The facilitator is there to make sure everyone's voice is heard and to navigate conflict. This helps build up confidence so that team members can share freely in the retrospective, eventually going as far as sharing issues at any time which is the ultimate goal. <br />
<br />
Sharing issues never go away. Team members can revert to not sharing if the team goes back into a storming mode. That said, my own experience is that if you've done your job right, they still feel that the retrospective is a safe place. This is why it's so important to continue it as a practice even if teams feel they no longer need it. </div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0tag:blogger.com,1999:blog-8990029112105182110.post-65624599791355791662012-04-26T13:21:00.000+01:002012-04-26T13:21:03.272+01:00Scrumbut isn't always a bad thing<br />
<span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">There have been discussions for many years about the need to </span><b style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">always</b><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;"> do Scrum by the book. I think this statement might be true for some teams, but not all. I'm not talking about having a half-arsed Scrum adoption, but allowing your teams to evolve beyond it </span><b style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">when they are ready</b><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">. The last four words of that last sentence are critical. There's a dichotomy within the framework, we are expected to inspect and adapt, but not in ways that adapt set parts of the framework. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">The mantra of, do it by the book, seems to have grown out of problems with teams that only adopt parts of the framework and then wonder why it's not working. Hence the name scrumbut, we do Scrum but.... Agile and/or Scrum are often the obvious scapegoats rather than looking into internal problems.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">For your initial scrum adoption </span><b style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">I do</b><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;"> recommend that you do everything by the book. Also hire some seasoned ScrumMasters to help you out. Though Scrum is a simple framework, sending someone on a 3 day course and expecting them to be an expert is naive at best. Another option is to hire an agile coach to work with your newly minted ScrumMasters. I can't stress this more. Don't go it alone. If you're serious about agile, then take it seriously and hire the right people to teach others. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Anyway getting back to the point of the post. I'm a great believer in the martial art concept of Shu, Ha, Ri (which I was introduced to by Lyssa Adkins in her Coaching Agile Teams book).</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Shu - learn the rule. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Ha - break the rule. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Ri - be the rule.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Teams start in Shu, i.e. do Scrum by rote. This is essential so that teams build up the discipline needed for a successful adoption. It doesn't mean that you can't ask questions as to why something is done a specific way. In fact that is encouraged, but you aren't ready to adapt away from the constraints of Scrum. This is where a seasoned ScrumMaster or coach is essential. They'll be able to give knowledgeable answers to any questions that arise and know when a team is ready to move to the next state. Ha.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Note: teams might be at different levels for different practices. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">When teams have achieved Ha, the ScrumMaster will start letting them break existing rules. This will allow the team to learn, but without the discipline that has been built up they won't have a frame of reference. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Lots of teams want to skip directly to Ha or Ri stages without going through Shu.</span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Finally as the team learns through breaking the rules they'll achieve Ri. This is the state of high performance. Teams will be able to inspect and adapt how ever they want. At this stage, they may have evolved their Scrum practices in a way that would be considered Scrumbut, but they now have the experience to understand why they've done it. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Finally, I believe there's a conflict of interest here with certifying organizations. If teams keep on changing their process, they may no longer fit the model of strict Scrum and have no need for certifications. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Remember that Scrum is a starting place on your agile journey, not the final destination and not the only way to get there. </span><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><br style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;" /><span style="background-color: white; font-family: arial, sans-serif; font-size: 13px; line-height: 18px;">Are you doing Scrum by the book, in ways that would be considered Scrumbut? Do you think Scrum by the book should be the only way to do it?</span>
<br />testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com1tag:blogger.com,1999:blog-8990029112105182110.post-88430536625083659122012-04-10T19:25:00.001+01:002012-04-10T19:25:14.371+01:00Breaking flow at the end of the work day<div><p>It's getting towards the end of the work day, you're cranking, feeling great and everything is just clicking into place. You notice the clock in the bottom corner of your screen and realise that you could maintain this state for a few more hours, but that will get you home late. You don't want to stop but you know you have to go. What do you do?</p>
<p>This is a situation that I find myself in a few times a week. My family commitments mean that I really need to leave on time unless there's a work related emergency. The problem is that I don't always want to leave. This isn't because I don't want to go home, but because I'm in a state of flow and find it hard to switch off. I tend to end up working until the last second and then running for my train. On the first half of the journey home I'm mentally coding and getting stressed out because I can't actually code. This stress is caused in part by not having a transition period between activities.</p>
<p>Transition periods are quiet times between activities which help you go from one activity to the next without added stress. These transitions are often combined with a ritual. </p>
<p>For example, when I get into work the first thing I do is get a coffee and read a few blog posts for about 10 minutes. If this transition ritual is interrupted my stress immediately goes through the roof. </p>
<p>I do have a transition ritual for the end of the day, but when I'm in a state of flow I don't do it. Yes I could force myself to wind down but this also creates stress. </p>
<p>I feel like I'm between a rock and a hard place, so I'm wondering how others deal with this situation. How do you break flow without causing too much stress?<br>
</p>
</div>testhttp://www.blogger.com/profile/05320199098014551969noreply@blogger.com0