Tag: project management

Keeping it Lean: Building the Bare Essentials for Project Management

When you’re running a project that needs to stay lean — and I mean lean like taking a cargo bike to grab groceries instead of a 2+ ton automobile that’s slower, more cumbersome, and way overkill for the job — the tools you choose and the processes you define matter as much as the work itself. It’s easy to go overboard, drowning in Gantt charts, sprint boards, and daily standups that spiral into mini-retrospectives. But what if the goal is simplicity, agility, and clarity?

Let’s break it down.

1. Define Your Central Hub

The first thing you need is a single source of truth. This doesn’t mean a bloated Jira instance with workflows for every imaginable scenario. For a lean project, a simple Kanban-style board can do wonders. Tools like Trello or GitHub Projects (especially if you’re already using GitHub for version control) offer clean, intuitive interfaces that keep everything in one place.

Continue reading “Keeping it Lean: Building the Bare Essentials for Project Management” →

Transform Your 1:1 Meetings: From Status Reports to Meaningful Conversations

Let’s face it—1:1s often feel like a chore. They can seem awkward, unnecessary, or even stressful, especially if they devolve into nothing more than a glorified status report. These meetings are supposed to be about meaningful dialogue, yet too often, they become just another checkbox on the to-do list. If you’ve ever found yourself reciting project updates that could’ve been sent in an email, you’re not alone.

But here’s the thing—when 1:1s turn into status reports, they lose their value. And that’s a big problem for several reasons:

  1. Missed Opportunities
    Turning 1:1s into routine updates means missing out on the chance to discuss your personal growth, career aspirations, or challenges that need attention. This time is carved out for your development and support. If you’re not using it wisely, you’re letting potential progress slip through your fingers.
  2. Lack of Connection
    When your 1:1s are all about status updates, you miss the opportunity to build a deeper connection with your manager. Understanding your manager’s goals and challenges is key to aligning your work with the broader mission of the team and company. Without this connection, you risk becoming isolated, working on tasks that don’t fully align with the bigger picture.
  3. Increased Frustration
    If 1:1s feel like just another meeting to get through, they become something you dread rather than look forward to. When these meetings lack substance, they turn into a time-waster, leading to frustration and disengagement.

So, how do you change the dynamic? How do you make 1:1s less cumbersome and more valuable for both you and your manager? Here’s how to flip the script:

Make Your 1:1s Count:

  1. Ask for What You Need
    Use your 1:1s to ask for the resources or support that will help you grow. Need career advice? Ask for it. Facing a roadblock? Seek help to get unblocked. Want to meet someone influential in your field? Request an introduction. This is your time—make sure you’re using it to your advantage.
  2. Understand Your Manager’s World
    Instead of just sharing your progress, take the time to ask your manager about their challenges and goals. What’s their biggest concern right now? What are they focusing on? Understanding what’s on your manager’s mind can help you better align your efforts with the team’s priorities, making you a more effective and valuable team member.
  3. Learn About the Business
    1:1s are an excellent opportunity to get a deeper understanding of the business. Ask about the company’s growth areas, the challenges it’s facing, and where your work fits into the bigger picture. Having this insight not only makes you more informed but also more strategic in your contributions.
  4. Seek Feedback Regularly
    Don’t wait for annual reviews to get feedback on your performance. Use your 1:1s to ask for continuous feedback. What are you doing well? Where can you improve? Regular feedback helps you course-correct quickly and ensures you’re always moving in the right direction.
  5. Discuss Long-Term Goals
    Use your 1:1s to discuss your long-term career goals. Where do you see yourself in a year or five years? What steps can you take now to get there? This helps ensure your day-to-day work aligns with your broader career aspirations and keeps you motivated.

For Managers:

As a manager, your role in 1:1s is crucial. If you’re not careful, these meetings can easily become stale and unproductive. Here’s how to ensure they stay valuable:

  1. Foster Openness
    Create an environment where your team feels comfortable discussing more than just their work progress. Encourage them to bring up their challenges, ask questions, and share their career aspirations. This openness builds trust and helps you better support your team.
  2. Share Your Perspective
    Be transparent with your team about your own challenges and objectives. This helps your team understand the context behind decisions and aligns their efforts with the company’s goals. Transparency also makes these meetings more engaging and less about checking boxes.
  3. Focus on Growth
    Your 1:1s are an opportunity to mentor and guide your team. Use this time to help your team members grow, providing the resources and support they need to advance in their careers. When your team thrives, so do you.
  4. Set Actionable Goals
    Work with your team members to set clear, actionable goals during your 1:1s. These goals should be specific, measurable, and aligned with both their personal development and the team’s objectives. Setting and tracking progress on these goals gives your 1:1s direction and ensures they’re driving real impact.
  5. Provide Regular Feedback
    Make feedback a regular part of your 1:1s. Don’t wait for formal reviews to give your team members insights into their performance. Regular, constructive feedback helps them improve and stay aligned with the team’s goals. It also shows that you’re invested in their development.
  6. Create a Safe Space for Honest Dialogue
    Encourage your team to speak openly and honestly in 1:1s. Let them know that this is their time to share what’s on their mind without fear of judgment. Creating a safe space for dialogue ensures that issues are addressed early and that your team feels heard and supported.

Conclusion:

1:1s don’t have to be a burden—they can be one of the most powerful tools for growth and connection in your work life. By shifting the focus from status reports to meaningful conversation, you’ll find these meetings become not only more productive but also more engaging and rewarding.

What strategies have worked for you in making the most out of 1:1s? Let’s share and learn from each other—drop your thoughts below! 👇

My Current Windows Development Machine Software Stack

I recently did a clean install of Windows 7 64-bit.  It had been a really long time since I listed the current tools, SDKs, and frameworks that I’ve been using.  Thus here’s my entourage of software that I use on a regular basis that is installed on my primary development machines.

Basic Software & System OS

Administration Utilities

Themes & Such

In addition to these packages of software another as important, if not more important to my day-to-day software development includes these software services and cloud hosting services.

SaaS, PaaS, and IaaS

Software I will be adding to the stack within the next few days, weeks, and months.

Waterfall vs. Agile

Before reading this you should know what the Agile Manifesto is and the Agile Principles are.

I’ve seen it on more than one project in my career and it always seems to happen.  Agile rarely gets credit in this scenario.  People rarely learn what was and was not effective on the project in this scenario.  Those that are Agile Practitioners that know what a truly fast paced, effective, high quality, and successful software project can be know.  What I’d like to know though, especially from those that have successfully dealt with the “Must have big design up front (BDUF) headaches” and transitioned those people to a more Agile style approach.

The scenario generally starts like this…

A project is green-lighted for whatever reason.  Often with some high level manager determining that a project will save or make $X amount of money.  The project is poorly defined or simply not defined at all.  The stakeholders, clients, or others that would prospectively use the software are nowhere to be found and unidentified by management.  There are at least a half dozen external dependencies the project must have completed.  (Take Note Upper Management & Executives:  Six Sigma/Lean Processes can help at this level dramatically)

Waterfall Approach

In a waterfall approach all of these things will have to be documented and nothing initially gets developed.  The people writing the documents, often some sort of business analyst, is forced to basically make up whatever they can come up with.  In addition to that and hypothesis is derived from thin air and someone starts to come up with a more functional, technical, or even concrete UML design documentation.  To summarize, in a waterfall approach a whole bunch of people start documenting all sorts of things about this theoretical application software.  A 6th grader would study this and say, “so they write a bunch of lies right?”

When the actual concrete ideas come to fruition, long hours of the famous death march approach usually start.  Sometimes more and more people are thrown at the application in hopes that somehow it will speed things up, but in reality as a seasoned software developer knows, it only slows them down.  Other issues very common with this approach are horrifying low code quality, a lack of tests, missing ability to regression test, no verification of what done truly means, and a whole host of known issues.

Agile Approach

An Agile approach on the other hand would start finding the clients and consumers of the theoretical software.  These people would be engaged and some paper prototypes or other initial sketches of what the software might do are created.  Maybe sketchflow or some other software is used to create some rapid prototypes to give the clients an idea of what the software would look like and what it might do.  The clients start giving feedback and a more concrete idea is formed around this theoretical software upper management has dictated.  Initial tests and code are written and put into a continuous integration process, with an end product being dropped every few days or weeks.  A 6th grader would study this and say, “you’re building software and having fun?”

What Happens in the End, IF the Waterfall Project is Successful

There seems to be two resolutions that I’ve found that allow Waterfall to actually be successful.  The first is that the project forgoes the charade of Waterfall and starts implementation of more Agile ideals and processes immediately.  This cleans up things and improves morale, all while getting the project back on track.  The second solution is that development/engineering determines they’ll do Agile anyway, and up manage the management.  Management thinks they have a successful Waterfall Project when in reality the proactive developers/programmers took it upon themselves to assure success, and thus moved to an Agile ideals, process, and practices among themselves.

In Summary

These two different models are HUGELY disparate, and yet the aforementioned waterfall model approach is still heavily used.  I suspect, unfortunately, that it is primarily used at a majority of businesses (and especially Government).  Even if the business or Government pretends they’re doing Agile and calls their Waterfall Model Agile something another.  This is something else I’ve seen far too often.  This is a complete misrepresentation of what Agile Ideals and processes are.

The Questions

I’d like to know, what methods do you use to attack and remove the barriers caused by waterfall at large organizations?  Do you subvert the existing management infrastructure and just do things in a more Agile way regardless in order to succeed?  Are there any specific practices, techniques, or otherwise that help you align so that one can keep a project moving along quickly, all while avoiding the damage waterfall models do to the actual underpinning project, code quality, and other such items?

Please leave a comment or three.  🙂

Those People That We’re Always Looking For…

I’ve been rereading Joel Spolsky’s “Smart and Gets Things Done”.  His writing style is entertaining.  I’m not always in 100% agreement with the guy, but who ever agrees 100% with anyone right?  However, Joel has a ton of things that are smart, well thought out, and when one pays heed can really help out during the course of a software project.  Since I’ve been writing on this topic lately, I figured it would be a great idea to give this a read and maybe even add my two cents to a few of his passages.

I didn’t get very far and I had already found one bit that I wanted to elaborate on.  This part was in remark to hiring college interns and the fact that the best college students are often already good programmers.

“The good news about our field is that the really great programmers often started programming when they were ten years old.  And while everyone else their age was running around playing “soccer” (this is a game many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux Kernal to compile.  Instead of chasing girls in the playground, they were getting into flamewards on Usenet about the utter depravity of programming languages that don’t implement Haskell-style stype inference.  Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access Wi-Fi point, all the images on the web appeared upside-down.  BWA HA HA HA HA!”

This got me thinking.  I’d like to find programmers who have started a band, chased the girls, played soccer, flipped the images, argued the Haskell points, compiled a Linux Kernal (or two or three), and more.  I don’t want the all exclusive nerd only programmer, because today they’re often not that useful on software projects.

When I’m looking for other developers to hire and work with I want a number of things.  The technical bits are of course important, very much so, but I want to work with developers who know about all sorts of things.  I want programmers that know why financial application development pays well and non-profit work doesn’t, I want them to know about the successes and losses of business endeavors within the software industry.  Most importantly, I want them to be personable, approachable, and interested in life beyond just hacking lines of code 24/7.  Nothing wrong with the later, but that is only helpful for about 20-40% of the time on a project.

Warren Buffet looks for the criteria of “integrity, intelligence, and energy”.  I’m curious, readers out there in reader land, when you’re looking to work with a team or hire a team member what do you look for?  What are some key indicators besides the white board coding questions and technical bits?