tag:blogger.com,1999:blog-19635803486657780272024-02-20T19:56:54.396+00:00Software Development - People & ProcessesA philosophical view of software development.c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-1963580348665778027.post-13163981684184649962015-06-18T10:28:00.002+01:002015-06-18T10:32:44.100+01:00Estimates, Risk & ROIToday I got involved in a friendly debate about Cost Estimates in product development or project management.<br />
<br />
In particular I responded to this statement from @PeterKretzman:<br />
<br />
"Implicitly or explicitly, you can't make a purposeful decision without 'estimating' cost."<br />
<br />
He in turn was responding to a tweet from @duarte_vasco, who is of course an advocate of the #NoEstimates movement.<br />
<br />
Firstly let me say that I am not a vocal advocate of the #NoEstimates movement. I've read the literature and applied it to my experience and other things I've read, but I don't feel strongly enough about it to be trying to raise awareness of it, or get more people to consider it.<br />
<br />
In reading the quote above today though, I challenged myself to think about whether the statement was true or not, and asked the OP whether he had considered fixing the cost, and instead estimating the value that could be achieved for this cost, to achieve the same goal as [I imagine] estimating the cost. Namely; Is the ROI sufficient that I will take the risk.<br />
<br />
Risk is what I want to talk about next, because all of this, for me, comes down to professional management of risk. ROI is a calculation of Return (reward) received based on the hope that Investment (cost) will provide.
If we assume that Return and Investment are variable:<br />
<br />
e.g. [We believe that ] our company needs a new way to bill our customers.<br />
<br />
==> The hypothesis is perhaps that some customers prefer certain billing types, and that providing more options for billing will generate an increased chance of converting a sales lead into a paying customer.<br />
<br />
==> We _estimate_ that in order to build the functionality, we will incur total costs of £XXXX.XX and XXX weeks<br />
<br />
==> We _estimate_ that the increase in conversion will generate an addition of £XXXX.XX in sales/annum and/or profit, and as such can calculate the point at which the work will have paid for itself, and project ROI into the future.<br />
<br />
Because we've estimated, that implies uncertainty. The cost is uncertain and so is the conversion uplift. Uncertainty is risk in this context. If the cost estimate is negatively off, but the conversion uplift is accurate then the ROI is screwed. If the cost estimate is accurate but the conversion uplift doesn't materialise, then the ROI is screwed. If both are negatively inaccurate, then we're really screwed.<br />
<br />
Consider an alternative:<br />
<br />
[We believe that] our company needs a new way to bill our customers.<br />
<br />
==> The hypothesis is perhaps that some customers prefer certain billing types, and that providing more options for billing will generate an increased chance of converting a sales lead into a paying customer.<br />
<br />
==> We _estimate_ that the increase in conversion will generate an addition of £XXXX.XX in sales/annum and/or profit.<br />
<br />
==> Based on the estimate of value, we _fix_ the investment we are willing to make to find out whether we are correct. No estimate of cost [implicit or explicit] is required.
Because we've estimated, that implies uncertainty. The conversion uplift is uncertain. Uncertainty is risk in this context. If the conversion uplift estimate is off, the ROI is screwed.<br />
<br />
The cost wasn't estimated though, it was fixed. We've removed some element of uncertainty and in real terms ensured that we've limited our risk.<br />
<br />
And this fixing of cost Doesn't need to be as constraining as it may sound. Imagine if its just a hard decision point, where we can choose whether to invest further or not? If you've heard of the sunk-cost fallacy, hopefully you'll recognise the value that creating this decision point [which gives you options] provides?<br />
<br />
So what am I not saying?<br />
- I'm not saying that fixed cost is the way to go for everything<br />
- I'm not saying that you can focus only on the return (value) and not on the investment (risk).<br />
- I'm not saying that estimating is bad in any way.<br />
<br />
What am I saying?<br />
<br />
- In risk lies opportunity, but risk should be actively managed, and using past performance etc to predict or estimate ROI can be a useful way to manage risk.<br />
- I am saying that logically, if the cost can be infinite, you can fix the return you want but typically it is more pragmatic to fix the cost and gamble instead only on the return.<br />
<br />
Feel free to let me know what you think.c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com5tag:blogger.com,1999:blog-1963580348665778027.post-83866197989642707712015-03-19T15:20:00.003+00:002015-03-19T15:20:56.229+00:00Faking it until you make itThanks to Gemma Cameron (@ruby_gem) for providing the impetus for me to blog again for the first time in ages.<br />
<br />
A colleague of Gemma's - Jim Jeffries (@jjeffries1) tweeted today that breaking a waterfall project into sprints didn't make you agile.<br />
<br />
Whilst I agreed, I felt that I'd been noticing that certain practices could yield benefits to teams even if their understanding of them, or more importantly *why* they were followed was quite shallow, and so I asked whether Jim felt that it could be a step in the right direction.<br />
<br />
For instance, imagine a new starter into a team which observe a healthy daily stand up meeting. Does this person need to know the alternatives to this ceremony and have a deep appreciation of the principles which went into formulation of this ceremony, in order to enjoy its benefits?<br />
<br />
Jim clarified that in his scenario, the only change from waterfall he was thinking of was to call each phase of the waterfall project a sprint, for example Sprint 1 == Analysis, Sprint 2 == Design etc.<br />
<br />
Had this not been the case, had the scenario been breaking a long waterfall project into sprints but also enforcing that a product increment be released at the end, then I think that its possible that this might be a beneficial step towards agility - even if no depth of understanding was reached.<br />
<br />
I think that a person's 'journey towards agility' is quite fractal, and that you can keep coming back to old practices and beliefs and re-analyzing them after you've had new experiences and learned new things.<br />
<br />
And I think that you can, in some contexts, "fake it until you make it" by copying the practices of those who have been on the journey before you, and still gain at least some of the benefits.<br />
<br />
<br />c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com0tag:blogger.com,1999:blog-1963580348665778027.post-46566519025340287832011-05-05T22:02:00.001+01:002011-05-05T22:03:32.302+01:00DDD - a cute suggestion for naming of repositoriesTonight I've been messing around with some code in a TDD code-kata fashion, coding for practice as much as anything else. I decided to start to implement an order management system with CMS-like functionality, as a home project I could use to keep my interest over many nights of toil.<br />
<br />
Anyway, I started to create a repository class - see Eric Evans Domain Driven Design (DDD). This class would be responsible for handing me my SalesOrder aggregate root entity from some obscure infrastructure that my domain didn't need to know about. I found that I was struggling with what to name this class. I was torn between SalesOrder (which seemed more pure domain language-ish but could cause me later confusion between that and my SalesOrder entity, and SalesOrderRepository (which gave me the separation I craved but didn't seem to fit with Uncle Bob's clean code naming guidance, nor Evan's ubiquitous domain language!).<br />
<br />
I Googled around a bit as is my wont, and found a <a href="http://fragmental.tw/2010/12/23/how-to-write-a-repository/">really interesting webpage</a>. Let me share with you what it advised:<br />
<br />
Instead of calling my repository either SalesOrder or SalesOrderRepository, what if I called it AllSalesOrders. This is:<br />
<br />
<ol><li>Very domain languagey</li>
<li>Forces me to remember at all times that I am operating on/with a list</li>
<li>Gives me some really elegant looking client code like allSalesOrder.For(customer) and allSalesOrder.ForDeliveryOn(date)</li>
<li>Makes it pretty darn easy for me to spot when I've broken the single responsibility pattern allSalesOrder.AddCustomer(customer)</li>
</ol>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com6tag:blogger.com,1999:blog-1963580348665778027.post-24654176416248276672011-04-17T09:43:00.000+01:002011-04-17T09:43:06.066+01:00Motivation 101 - what is it, why do I crave it and how do I get it?So today I've been reading around the subject of motivation. I'm mostly concerned about how I can get a better level of motivation from my team, but if I can learn the tools to motivate a few other people around me at the same time, so much the better!<br />
<br />
What is motivation anyway? You cant touch it, you cant buy it (not directly anyhow) and you cant seem to train it in. For the purposes of this blog, when I say motivation, I mean passion, dedication, enthusiasm and all of those other words that in the workplace roughly translate as someone who enjoys their work and so goes the extra mile to make a really great job of it.<br />
<br />
<a name='more'></a><br />
Why do I want this motivation? The answer is two-fold:<br />
<ol><li>I want my team to be the best team in the department, no company and through their rise to greatness, achieve some recognition for myself (and and easier more fun work life!)</li>
<li>I want the best for them. I have to work with them every day and if they are miserable because they aren't motivated, then they'll crash me out too.</li>
</ol><div>Now for the hard part, how do I get it from my people? In order to answer the question, we need to understand where it comes from. I haven't done primary research for this, so instead I'm going to lean heavily on <a href="http://www.kaisen.co.uk/pdf/what-really-motivates-people-at-work.pdf">this whitepaper</a> by Kaisen Consulting (who have done the research!).</div><div><br />
</div><div>The good folks at Kaisen sent out 250 questionnaires asking people what made them feel good and bad at work. The assumption they make is that the good factors positively affect motivation, and the bad detract from it.</div><div><br />
</div><div>The first interesting finding they made was that 3 types of response stand out by some distance in terms of how many people said them:</div><div><ol><li>Achievement - Doing something that you feel is worthwhile.</li>
<li>Working with others - this one fascinates me as I've seen a lot of people not wanting to work with others in my career</li>
<li>Getting recognition for your achievements.</li>
</ol><div>The Kaisen paper also tallies up the frequency of which people reported the bad things at work. Of these the top few were (in order):</div></div><div><ol><li>Negative experience with a colleague</li>
<li>Lack of recognition</li>
<li>Politics</li>
<li>Stress</li>
</ol><div>So, as a working theory, what if I were to try to add more of the good stuff into my team, and remove some of the bad stuff, would that increase the motivation I saw? Do I need to measure my people's motivation to be able to see if what I'm doing helps or hinders?</div></div><div><br />
</div><div>I don't have all the answers yet, but this is a marathon, not a sprint. Motivation is a work in progress for me and I'll share my learnings here.</div><div><br />
</div>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com7tag:blogger.com,1999:blog-1963580348665778027.post-80916439882389844262011-04-14T20:18:00.001+01:002011-04-17T09:07:56.618+01:00The importance of a good working environmentSo, a couple of things have happened at work today to make me think about how much the working environment can affect the quality and speed of our delivery.<br />
<br />
<a name='more'></a><br />
Firstly, I saw one of my developers making excellent use of the 24" widescreen monitor he's just installed.Up to now, my opinion on monitors for software developers has always been that more is better. I myself work with 2 19" monitors. When he joined, this guy requested instead to have a single 24" widescreen to complement the 17" screen that comes with his laptop.<br />
<br />
When I looked over his shoulder today, he was doing TDD on the monitor whilst having both the test class, and the class under test, open simultaneously. The productivity gain he was getting from working this way was phenomenal, and when I thought about it, the same effect could have been achieved had we all had VS 2010 which supports multi-display.<br />
<br />
The second thing was a discussion about some of the problems we get form time to time were people have worked in silo's or alone instead of collaborating with others who were vested in the task. One of the BA's (quite new to the company) offered the opinion that she felt reluctant to descend upon someone in another team's desk to collaborate because of the noise and close proximity that were currently working in. A casual factor to this is our reasonably heavy recruitment drive of late, which has meant that whilst we look to solve the space issue, there are more of us in the office than is truly sensible.<br />
<br />
If either of these things had happened on another day, I might not be writing this now, but because they did I started to think about really just how important the space a person spends his working life in is really really important.<br />
<br />
As a developer, the below are things that I crave in my working environment, and without these things, my productivity, motivation and possibly even willingness to team are negatively affected:<br />
<br />
<ol><li>A comfy chair - properly adjusted with lumber support!</li>
<li> 2 or more nice big monitors - or as my colleague proved - one gigantic one can have the same effect</li>
<li>A 'lean' (minimum bloat-ware) computer which has grunt to spare. - If this is a dev spec machine, it needs CPU and RAM aplenty</li>
<li> The right tools - I could not live without ReSharper, Subversion, Cruise Control etc</li>
<li> Plenty of stationary - Post its, stickers, blue tack, brown paper etc</li>
<li> Whiteboards - I get nosebleeds if I'm ever too far away from a whiteboard & dry wipe pen at work</li>
<li>Plenty of quiet - developers get in 'the zone' to get tricky bits done. Context switching or loss of concentration can cause them to lose hours of productivity a day.</li>
<li>Breakout/collaboration areas - Again, quiet but comfy places to commune</li>
<li>Ability to move - I've started getting my devs laptops instead of PC's. The loss of grunt these days is non-existent and the added mobility should allow us to quickly create physically co-located cross functional teams. We're not there yet as an IT department, but it;s on my To-Do list.</li>
<li>Books - the internet is great but there's still a lot of value in keeping some top drawer books around the place. The quality of literature is generally higher per page, you can literally throw them at people when they have a problem you know the book addresses, and they can be a conversation point for non team members.</li>
</ol><div>This list is by no means exhaustive, but I think by reading what I've put and thinking for yourself about your current working environment, you'll be able to spot an opportunity to make your place of work that little bit better for you and yours. Whatever it costs, it's a sound investment.</div>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com4tag:blogger.com,1999:blog-1963580348665778027.post-86778355448309330322011-04-12T07:57:00.003+01:002011-04-12T18:45:28.865+01:005 ways to make yourself a better software developer - without learning a new tool, process or patternWithout resorting to stereotype, developers can sometimes focus their time and energy so much on the tools and the code, that they struggle with the softer side of the job including communication, teamwork & planning. In the workplace this can cause friction and be to the detriment of the product or delivery.<br />
<br />
In my experience, there are a few things that you can do as a developer to combat this problem, in yourself and in your peers:<br />
<br />
<a name='more'></a><br />
<ol><li>Immerse yourself in the business problem - before the product.</li>
<ul><li>Use the businesses terminology for your entities - it will make communication so much easier</li>
<li>Spend time with the users (not necessarily the stakeholders) - see their pains and understand their fears</li>
<li>Look for opportunities as well as threats - people can sometimes fear change, is there some opportunity to make them adore the new feature by simplifying/clarifying their experience?</li>
</ul><li>Be close to your business analysts</li>
<ul><li>Don't be precious about your role - you probably have nearly as much analysis experience as your BA, so use it to their advantage by offering your help.</li>
<li>Make them like you - this is really important. There needs to be no barriers because you can only really build to their quality of requirement. Make time in your day to find out about their interests outside of work or family.</li>
<li>Collaborate - Don't have a 5 minute conversation before composing your documentation in isolation from each other. Don't communicate with them via email.</li>
</ul><li>Learn</li>
<ul><li>Know what your soft-skill capabilities are and spend some time developing them as you do your technical skills</li>
<li>Ask for peer evaluation of your soft skills periodically, and plan what to focus on improving next</li>
<li>When you're driving home at night, reflect on the interactions you've had with people during the day. Be your worst critic and decide what you'd do differently if you had your time over again</li>
</ul><li>Teach</li>
<ul><li>Don't keep the techniques and skills you learn to yourself. Evaluate your peers and help yourself by influencing them in the areas they need to improve. Can you do this without them realising? So much the better.</li>
<li>Talk to people about how important soft-skills are - in addition to your covert operations, simply asking people what their opinion on say 'teamwork' is can provoke a discussion that can be to their benefit and yours.</li>
<li>Consider doing something in the wider software development community. I hesitate to use the word 'evangelise' in our industry these days, but that's really what I'm talking about.</li>
</ul><li>Be honest and brave</li>
<ul><li>Honesty in software development is crucial. As a rule I would always follow this simple process: Say what you intend to do, do it, say what you've done. Admit when you goof, as early as possible but with a plan in your head of how you can avoid the mistake in future.</li>
<li>Bravery is about; not taking the popular line simply because its popular, playing devil's advocate when an opinion has not even been considered, don't allow people to be dishonest with you - ask questions until you are sure of their real intent/motivation.</li>
<li>Cut the apron strings. It's oft quoted but I find it immeasurably true; Ask for forgiveness rather than permission. Using your initiative more and more will build your confidence and allow you to be brave and honest.</li>
</ul></ol><div>The above is by no means an exhaustive list, but I think it's a good reference point for you to reflect on how you work. Feel free to comment on what you think I've missed, got wrong, or you don't understand.</div>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com3tag:blogger.com,1999:blog-1963580348665778027.post-11201129876923275552011-04-09T20:59:00.002+01:002011-04-12T18:45:05.591+01:00AgileSo this week, like a viral you tube clip, this <a href="http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html">old blog post</a> from Steve Yegge did the rounds in my team.<br />
<br />
<a name='more'></a><br />
Firstly, let me say; Steve really has a voice. His dry sense of humour has you lapping up whatever idea he's trying to sell you on.<br />
<br />
This means you have to be careful though. You really need to strip out the amusing anecdotes and witty analogies and get to the core of what he's saying before you can decide whether you really agree with what he says. I read the entry the first time, and it had me really swept up in the flow of his tirade, and I genuinely started questioning whether Agile was a faddy new methodology concocted only for a few guys to make some money from. The comments do even more damage, written mostly as they are in a tone of religious fervour and anger.<br />
<br />
I agree with Steve that there is bad Agile and good Agile, but I don't think that they are as he describes them. I also don't think that at the time of writing, he was fit to suggest that anyone who worked with a deadline in mind was 'doing it wrong'. Agile is a lean process, it's about stripping out anything in the process that doesn't add real value, and putting things in place that do.<br />
<br />
Finally, Steve suggests that due to the difficulty in quantifiable evidence that Agile makes things better, that it is more akin to a Religion - surviving on the faith of it's practitioners. I would concede him this point - almost. Science, at it's birth, was the idea of believing only what one could perceive with one's own senses. I can see and hear and smell the improvement in my team and my working life since we started to believe the principles of Agile, even if I cant directly measure the difference. It was this belief, rather than the adoption of the practices of Agile, that brought with it the benefits - and it came some time after we started using sticky notes.c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com3tag:blogger.com,1999:blog-1963580348665778027.post-3121698737389715882011-03-31T22:19:00.002+01:002011-04-12T18:44:55.302+01:00Belbin's perfect teamDr Meredith Belbin put forth a hypothesis that for every problem to be solved by a team of people, there exist nine distinct roles that each team member would have a natural psychological leaning towards a subset of. Furthermore, Belbin postulated that for a given problem type/complexity and known make up of a team, the success of the team could be predicted.<br />
<br />
<a name='more'></a><br />
Belbin's roles are:<br />
<br />
<span class="Apple-style-span" style="font-family: sans-serif; font-size: 13px; line-height: 19px;"></span><br />
<ul style="line-height: 1.5em; list-style-image: url(data:image/png; list-style-type: square; margin-bottom: 0.5em; margin-left: 1.5em; margin-right: 0px; margin-top: 0.3em; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><li style="margin-bottom: 0.1em;"><b>Plant</b>: Creative, Unorthodox.</li>
<li style="margin-bottom: 0.1em;"><b>Resource Investigator</b>: 'Fixer', gets the team what they need to succeed.</li>
<li style="margin-bottom: 0.1em;"><b>Co-ordinator</b>: Seeker of fairness & equality within the team, Encourager of input to all team members</li>
<li style="margin-bottom: 0.1em;"><b>Shaper</b>: Dynamic and loving of a challenge. Usually thrives under pressure.</li>
<li style="margin-bottom: 0.1em;"><b>Monitor-Evaluator</b>: Strategist. Contributes balanced emotionless opinion after careful judgement</li>
<li style="margin-bottom: 0.1em;"><b>Team Worker</b>: Fosters team co-ordination and relationships.</li>
<li style="margin-bottom: 0.1em;"><b>Implementer</b>: Practical, do-er. </li>
<li style="margin-bottom: 0.1em;"><b>Completer Finisher</b>: Concerned with the details. Good at spotting flaws and monitoring progress</li>
<li style="margin-bottom: 0.1em;"><b>Specialist</b>: Brings 'specialist' knowledge to the team.</li>
</ul><br />
<br />
<br />
<div><br />
</div><div>I've been in many teams where the people have been individually brilliant, and yet have struggled to perform as a team. Have a look at these team scenarios and see if they look familiar:</div><div><ul><li>The team sets off at a pace and before you know it there are well facilitated, in-depth analysis sessions, plans, and chunks of work flying out of the team. The pace is maintained and all seems well until right near the end of the task (for me usually post-live!), when from nowhere, something has been missed. Some aspect of the problem has not been addressed, or if it has, it is not fit for purpose.</li>
<li>The team seems to drift organically into sub-teams, with smaller groups of people working together on discreet aspects. Problems arise when each sub-team tries to marry up their work with the other team and it is apparent that communication and cohesion has been lost.</li>
<li>The team spends too much of its time deciding who will do what, and struggles to reach consensus. Ideas coming out of the team are often impractical or the delivery of them slips.</li>
</ul><div>Belbin's work offers us (I think) some insight into why these teams might struggle. Consider the first team; could it be possible that the team was missing a person to fulfil the role of completer-finisher, someone with a natural predilection towards ensuring the finishing touches are applied? </div><div><br />
</div><div>What about the second team? Is it possible that no-one had the group's cohesion at the top of their priorities? Would the addition of a natural co-ordinator have fixed the issue?</div></div><div><br />
</div><div>The third team may have been full of dynamic shapers, plants and specialists - strong characters each with a vocal opinion, but really lacked a practical implementer who just had a burning desire to get the job done.</div><div><br />
</div><div>As with (I imagine) all of the stuff I'll write in this blog, I don't follow Belbin's perfect team as a gospel. It is not a fix-all for teamwork. What I get from it, is a way of organising my thoughts around the balance that I think is important in a team. in my own experience, putting together a team of all-stars who share the same strengths often leads to poor performance. Personalities tend to clash rather than compliment, and important facets of teamwork suffer.</div>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com0tag:blogger.com,1999:blog-1963580348665778027.post-36578404778685328572011-03-31T21:31:00.000+01:002011-03-31T21:31:16.677+01:00Management PhilosophyI often beat myself up because time and again I fail to really solve the problems within and surrounding my team. What I try might go some towards my goal, other times the solution I come up with might make no discernible difference, and as a rare occurrence, even make the problem worse.<br />
<br />
Tonight I'm feeling more generous towards myself, and the events of the day have helped me reach the following conclusion:<i> Like in Philosophy, there is value in knowing the important questions, even if you cant yet see the answer. As in Philosophy, there is enlightenment to be found by peeling back the layers and dismissing those things that are definitely not the answer.</i><br />
<i><br />
</i><br />
If you, like me, occasionally stumble your way through myriad ideas, concepts, tools and technologies (all of which purport to make team working more productive, more efficient or just more), then tonight - just tonight, give yourself a break and a pat on the back for giving a damn and <i>never giving up</i>.c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com1tag:blogger.com,1999:blog-1963580348665778027.post-36219086819760729792011-03-30T20:09:00.003+01:002011-04-12T18:44:40.572+01:00People matterIf I could offer one bit of advice to a software developer, nay anyone who works with other people towards a common goal, it would be that people matter.<br />
<br />
<a name='more'></a><br />
Take a minute to reflect on the improvement initiatives your team has undertaken in the last 6 months. How many were new tools? How many were silver bullet methodologies? How many were focused on improving or even understanding the make up and core skills of the team? My guess is that the people development activities will have been fewer in number, and possibly only lip-service attempts to make things better.<br />
<br />
Now compare that to how important people are to what you do. Throw in your tools, your processes and every other factor you can think of that helps get the software out of the door and put them in order of importance. Be ruthless, imagine that you have to give up all but the most important. Anyone not think that the people are the one thing you cannot do without?<br />
<br />
Doesn't it then follow then that the most effort and time should be spent improving this most important of resources? I think so, and my intention for this blog is to share my journey with you as I meander through whatever literature and ideas I can find on understanding and developing people.<br />
<br />
I invite you, as a follower of this blog, to share with me your ideas and opinions, on what I write and what I dont.<br />
<br />
As a rough outline, I intend to:<br />
<br />
<br />
<ul><li>Learn some techniques to help me understand my people, what motivates them, and how I can profile them to better understand how to get the best out of them.</li>
<li>Understand how people learn, and apply it to things like employee induction, product/process training.</li>
<li>Figure out what it means to be a team, and what teamwork can achieve.</li>
<li>Capture the attitudes and behavioural patterns of the people that I want in my team, and work out how to transfer that into my recruitment.</li>
<li>Work out why some people seem to be resistant to change/improvement and what, if anything, I can do to overcome their reservations.</li>
</ul>c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com0tag:blogger.com,1999:blog-1963580348665778027.post-51006993275534367912011-03-30T13:05:00.000+01:002011-03-30T13:05:57.396+01:00What this blog is supposed to beHaving worked in software development for more than ten years, I have developed a lot of opinions & beliefs, but one stands out amongst the crowd: "You can have the best and latest tools in the business, but unless you have a group of people committed to a quality delivery, using processes that are comfortable and supportive, then your delivery is doomed."<br />
<br />
With this in mind, my intention with this blog is to talk about the things that, over a ten year period, have made the difference. I'm not a guru, I dont have all the answers, but I do have opinions borne of experience, and I offer them freely for dissection and discussion.<br />
<br />
Who am I? My background is in Microsoft bespoke development, latterly using .Net technologies. I have used many software development methodologies on projects ranging from tiny to Enterprise-ready and I now lead a small team of developers and continue to push for better and faster.c_phillips_2000http://www.blogger.com/profile/07428364102618489213noreply@blogger.com0