The Role of ScrumMaster / Software Development Lead / Manager

Remove impediments, improve the process. Understand what's being added to the backlog. Understand what kinds of "shortcuts" or workarounds are being taken by the team. Understand the consequences and better solutions to these items.

Plan for the next big problem

The stuff you're doing now will likely amount to something bigger and better once you're done. Keep doing what you're doing and getting better at it but keep in mind that there are consequences of what you are creating. Prepare for the consequences and get ready to tackle the next big problem they create when you get there; but only then.

Make the development process be THE KEY PROCESS

Development speed and efficiency might matter more than anything else. Yes, customer requirement and needs are paramount in general, but sometimes they are unclear and the development team can produce something really good that isn't EXACTLY what was corrected. This discrepancy is fine. If the development team can produce Product X which CLOSELY RESEMBLES the 'perfect product' described by the customer, then that is the product that should be produced. Future iterations can make it perfectly align.

Efficient workflow tradeoffs and cost

Workflow can be seen in two ways: that of the SYSTEM USER and that of the DEVELOPMENT TEAM. The end goal for most projects is to create a "perfect and efficient" workflow for the user. Being efficient may involve trade-offs as there is a cost for realizing perfect workflow. If the development team isn't paid for the realization of every incremental user workflow bit, then there is a problem.

Use the skills you have now to add as much value as you can now

Don't get bogged down doing a bunch of boring repetitive stuff now unless it is required. Follow the Pareto Principle http://en.wikipedia.org/wiki/Pareto_principle and knock out the big stuff. Demonstrate as much value as you can. Solve the problems you know how to but don't solve them throughout the whole system just yet. You can do that later. Yes, you'll develop a backlog of little stuff that has to be fixed; the time will later come when that is urgent.

Computer Programming is a Slow (, Fun?) Learning process for me

Yes, for me it's a very, very slow, tedious, painstaking one requiring much patience but the rewards seem to be many: it's very, very fun to learn so much and build a war-chest of solved problems that you can apply to the next situation. It's never-ending.

You learned it generally now, take the chance of applying it later

Any time you're unsure if adopting a new practice will help or hinder, don't adopt it. Go down the road on this project with the skills you have today and apply what you learned to the next project or iteration. Learning along the way is most of the fun but we don't have to apply everything we learned / are learning to our current project. We can do that later, in a future project! If you add the things you're learning to this project, you'll never finish; the project will grow and grow.

Today I'm working on a software app for my buddy Andrew. I'm having fun but the going's slow at times and I don't know everything. It is a forms application and the technology I've chosen to use is ASP.NET MVC (http://www.asp.net/(S(d35rmemuuono1wvm1gsp2n45))/mvc/) which I think is basically amazing, but I'm still learning it. In trying to solve the problem at hand, I read some VERY neat-sounding techniques from Brad Adams (http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-4-custom-object-templates.html) on automating form creation in ASP.NET MVC but I don't want to increase the scope of my project; I've got to finish knowing what I know now. I don't want to go down this rat-hole.

Brad's techniques look awesome and like they could save me a bunch of time later, when I have it. But I'm not going to invest in learning it now. I'll plod forward using the skills I have. I'm not a hacker, I am a software developer trying to produce working software as fast as possible. I'm not going to indulge in research activities right now.

Doing anything by yourself is very hard and there's always a better way to do something. There's always something to learn. The lessons we learn on our current iteration or project can be applied to our next iteration, later, when we have a chance to plan.

What’s a good project / program manager? A stable leader.

Someone who can stay afloat. Someone who is confident in their abilities and methods. Someone who is curious and perceives the world as dynamic and pliable. Someone who likes and trusts people. Someone who things that they and their peers are talented and having fun. Someone who can have tons of stuff thrown at them yet know the way forward and what to do next. Someone who is a planner. Someone with a plan. Someone who can backlog, prioritize and not burn out themselves or their teams. Someone who stresses out infrequently and contains it very well when they are stressed out. Someone who is cool under pressure. Someone with systems, standards and strategies. Somoene you want to work with who will not throw you under the bus or add unnecessary stress to your life.

Sometimes you may want waterfall development; but the luxury will cost you!

Sometimes you simply don't care about the specifics of what comes out the other end of the engineering process. Either because you have high expectations and high trust in what they'll deliver. "High engagement" with the engineering department will cost you time and energy. "Low engagement with engineering will cost you in time and rework, waste, and cost

There are times, like when a business person builds a prototype of a system or clearly defines the product requirements, that they can give that input to engineering to harden and tighten the design. In such a case, the inventor(s) of the prototype or specs may not really care what comes out the other end; their requirements are fundamentally qualitative: 1) Make it look good 2) Make it performant 3) Make it "tight". Managing a project in such a way is possible and sometimes desirable. But there are alternatives.

Not everyone wants to engage with an engineering group in an Agile / High Bandwidth way. They need room and space. They don't want to be an engineer. Weekly check-ins (like in Agile) seem reasonable but maybe some people would prefer monthly, quarterly, or annually. The larger the period between reviews and meetings, the larger the budget, the more the risk, the bigger the problems, the lower the quality.

Technology Things I’ve Learned Recently

Installing and using Eclipse. Installing WordPress and Drupal. Installing Drupal modules. Customizing Drupal. Things about ASP.NET MVC version 2.0. DataAnnotation in .NET. SSIS packages and catching error rows. Silverlight application development techniques. About RIA Services. There's a lot of great stuff out there.

Good Governance is Sitting Down with the Governed

You can write all the rules you want in an attempt to make people comply but the best way to get result and learn from others experiences is to sit down with them. Take the time to do this today!

Modified Version of Alvin Toeffler Saying

Coding is the easy part. The hard part is to discover and apply technologies that can continuously fit the business needs and problems.

The Users Need It Now!

Don't procrastinate. Get the software in their hands ASAP. The business process is the thing that matters and unless the tool or software is in-hand, you won't know what it is and what needs to change. Deliver now.

Hacking vs. Solving Root Cause – Level 1 and Level 2 Problem Solving

Stopping the bleeding and fixing what's in front of you is way different from solving the ACTUAL problem (not surface problem). I'll write more about this soon!

Capabilities Increase Scope

So ultimately it seems that having multiple developers changes the REQUIREMENTS of the solution and for that reason, the velocity. Assuming that all developers are stuck with where they are at with their own personal velocity until they read something great or get help from a peer. So if developer A knows how to do thing M and N and developer B can do thing O, then the total requirements for the solution are likely M, N, and O. For me, I'm operating on M and N now and the solution is "simple". If I could find someone who could do thing O, then it would take longer. Pragmatism is odd.

Individual vs. Team Work Velocity

It'd be very nice to always have a team (or at least a pair) of developers, but sometimes this isn't possible; sometimes we've got to 'go it alone'. I'm doing that right now on an app for my friend. I'm fairly good with the basics of getting things to print on the screen but when it comes to making things elegant and beautiful, I am way weaker. I consider these weaknesses "low pri" but if I had another person looking over my shoulder they may be able to help me. Right now I'm going to punt these things I can't do elegantly and am backlogging them with "TO DO:" statements in my code. This isn't a major concern but it raises the question for me of the difference between an individual and team's velocity. In an idea world, all developers would be able to work by THEMSELVES as fast as they possibly can. But there is overlap often, and people have to help people, and there is a team, so what would the net-net of adding people to a team be? Definitely more communication channels…

Find Ways to Tell Your Story to the People You Want, the Way You Want

If you're ever feeling frustrated, stuck, depressed, etc. don't get too down. Sometimes we feel like we're in a rut or mire that we can't escape and want to isolate ourselves from others, make decisions to protect ourselves and avoid interaction with people so we don't have to tell them a sad story or show them how bad or disappointed we feel on the inside.

As far as I can tell, people and activities are our best means for getting out of ruts. Find your believers and keep engaging them. Seek new believers, really anyone who will listen or share themselves. Keep talking, keep laughing, keep meeting people. Eventually you'll get to tell your story to the person or people you want in the way you want and you will feel very happy!

Punt the shit you can’t do well now

If you don't know how to do something now, don't do it. Do the bare minimum and put in a placeholder or wedge so you can move onto the next more important thing. If you are truly good at the rest of what you do (your trade) and getting the job (as you can do it, on time), you will attract supporters, followers, and believers. These people will be able to help you later and provide you with the time and support you need to complete the product or project on time, on quality and to your mutual enjoyment. Done is when everyone's happy, not when you're tired.

Incrementalism

Word of the day for me. It matters. Maybe more important than pragmatism? Do things in bites; bite-sized chunks. Remember your goal but focus on the near-term and task ahead. I'd rather do things small and incrementally (take baby steps and solve problems that are "bite-sized") than feel like I was eating an elephant. As long as we have enough time to break and breathe between bites of the elephant of life and our ambitions, we'll be fine. The elephant in fact is really the aggregation of all of the bites we are able to take of it. The elephant is fictitious to us and of a potentially infinite size. But don't make it so. Figure out how you can eat the elephant faster and more tastefully and who knows how many elephants you'll be able to eat!?

Sure, it's also great to have a vision and ambition and an appetite for eating lots of elephants and boiling many oceans, but you need to be able to (regardless of how large your challenge is…thank god you're not President of a nation or something ridiculous like that) do the next thing, take the next step, figure out what you CAN do next, successfully.

“Instrumented Reality”

We seem to want things to throw off data. We want to measure and see our world visually. Not just as they appear but with augmented reality; data overlays. We want to want to measure (in a computer system) what is going on around us.

Instrumented systems (see New Camera System that Takes the Guesswork Out of Baseball Stats http://www.popsci.com/technology/article/2010-01/taking-guesswork-out-baseball-stats) are our new databases. Many systems are now database information systems. They are organic and constantly changing yet digitized and software-enabled. We can present their data and rethink them however we want.

The world is apparently not good enough. What's up with that!?